Jump to content

Community Wishlist Survey 2021/Citations

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2021
Citations
12 proposals, 226 contributors, 326 support votes
The survey has closed. Thanks for your participation :)



Convert tools for different citations or citation styles

  • Problem: There is no easy way to convert a reference from one style to another.
  • Who would benefit: Editors who clean up references, and readers (consistency).
  • Proposed solution: The simplest and easiest step would be a tool to convert between similar templates. For example, I sometimes see an academic article or a newspaper using a cite web rather than cite news or cite journal templates. It shouldn't be that difficult to add a button for 'convert style' here - right now one has to regenerate or manually retype the citation. A more complex but very welcome tool would convert references between different styles, like Harvard/APA and so on, though I realize that's much more challenging. For now, again, the ability to convert between basic cite templates would be a step forward anyway.
  • More comments:
  • Phabricator tickets:
  • Proposer: Volunteer Marek (talk) 06:06, 3 December 2020 (UTC)[reply]

Discussion

Voting

Full reference in popup on hover over inline citations

  • Problem: Parts of this proposal are already there, but are not working (properly). When harvard citations are used (link to author and page number, which links to full reference further below) , the popup window on hover over inline citations shows only the author and page number. Full reference with clickable title in the popup would be much better as one would not need to scroll back upon actually checking or following the reference. Harvard style citations may be good for old-fashioned books (to save paper), but are completely unnecessary on the web. Two gadgets, Reference Tooltips and Navigation popups help a bit, but they clash with another popup that cannot be disabled, and are just partial solutions because they are page number (that's now sometimes added with the help of en:Template:Rp) agnostic.
  • Who would benefit: Every reader interested in checking the references and following links therein; especially important for online references
  • Proposed solution: There should be one reference per source, and if page numbers (chapter numbers, chapter titles) are to be given, the inline citation up in the text should contain it (hidden, until hovered?). When hovered, a popup window should display the whole reference, clickable, with all necessary information, page number relevant for that inline citation instance included. User should never need to scroll down, and back up, because there's nothing to keep track of these positions.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ponor (talk) 04:10, 17 November 2020 (UTC)[reply]

Discussion

Seconded. Seeing the full reference on pop-up is much more user friendly than seeing a part reference, then having to click and see the full reference. --// Lollipoplollipoplollipop :: talk 06:52, 17 November 2020 (UTC)[reply]

A possible greater extension of this would be to place the references list in a right hand panel that auto-scrolls to the closest or most recently clicked reference. Similar to the format used by some academic journals (E.g. journals published by Annual Reviews and Biomed Central). This particularly suits WP's strong focus on sources. T.Shafee(Evo﹠Evo)talk 09:58, 20 November 2020 (UTC)[reply]

Voting

Allow creating bibliographic entries with the Citoid tool in VE

  • Problem: Only references can be created with Citoid in the Cite tool VE, not bibliographic entries (same as a reference, but without the ref-tags). Currently these entries have to be written either manually or by cheating the Cite tool to produce the entry and removing the ref tags manually. This is beyond what can reasonably be expected from new editors.
An example of a bibliographic entry can be seen for example in this German Wikipedia article under the section "Literatur" whereas the references are created inside the text and displayed in the "Einzelnachweise" (References) section.
The Literature section does not seem to be common in the English Wikipedia, but it is very common in many other language Wikipedias.
  • Who would benefit: All Wikipedia editors, especially editors using VE primarily.
  • Proposed solution: Allow an option in the Cite tool to omit referencing or place the option somewhere else in the editing interface where it makes most sense.
  • More comments:
  • Phabricator tickets:
  • Proposer: Susanna Ånäs (Susannaanas) (talk) 09:12, 21 November 2020 (UTC)[reply]

Discussion

Voting

Tool for separating the references from the body text

  • Problem: Most often bibliographic references are directly mixed within the text and the code of the page. This considerably clutters the code of the page and makes difficult to locate the exact place where to do the needed additions or modifications directly in the page code, especially for long sections. This is a long problem affecting most of Wikipedia pages since the beginning. Even if some skilled contributors try to use Harvard name and date style and tricks with notes to locate all their references in the reference list at the end of the page, afterwards other contributors will directly insert their references in the body text of the page and the maintenance of the code becomes extremely tedious and a never-ending story.
  • Who would benefit: All contributors for an improved experience of editing the page code without being perturbed by the full references directly embedded in the code.
  • Proposed solution: To adopt the same approach that in all the references management programs (End Note, Reference Manager, Pro Cite, Zotero, Mendeley, ...). By clearly separating the in line citation in the text (with the reference name or ID only present in the text where the citation has to appear in the text) from the references data or code stored apart at the end of the page in the section reference. An interesting alternative is given in another proposal: it is to store the references directly in Wikidata as metadata for the page. Then an advantage is the centralization of all the references in one single place where the different Wikipedia sites could store, share, translate and discover all the common references.
  • More comments: Bots could be developed to assist for the migration of the references data or code at the end of each page in the references section or even better in one central place in Wikidata. I realize not to be the first for wishing such a feature. I already read this suggestion on different Talk pages and it is also probably discussed and advised in Wikipedia help pages and references templates since a long time. So, sorry to likely reinvent the warm water, but I think it is worth to insist once again on this never resolved issue in Wikipedia. I also realize the considerable technical challenge, or work, this could imply, but the question is certainly worth to be addressed once again and to find and implement a real solution. This will represent a real improvement in the code of each page. Aim: a cleaner and more accessible page code.
  • Phabricator tickets:
  • Proposer: Shinkolobwe (talk) 19:25, 24 November 2020 (UTC)[reply]

Discussion

@JAn Dudík and Jvs: Thank you for this information. I had a quick look at the proposed link with automatic translation from the Czech language to English, but I could not immediately find on the page a specialized function to directly do this job. I did not try to use the script too. So, I cannot presently assess if this tool is sufficient for solving the problems to be addressed but it could be a good first start. Thank you. Shinkolobwe (talk) 11:56, 25 November 2020 (UTC)[reply]
http://josef-svoboda.site44.com/wiki/wikiref2.html JAn Dudík (talk) 20:35, 25 November 2020 (UTC)[reply]
  • I'm not completely sure if this is what you are looking for, but if you need a tool to assist in moving inline citations into a references section in order to change them into so called list-defined references (framed by <reference></reference> or wrappers like Template:Reflist), in the English Wikipedia this tool might be helpful (to be added to your common.js):
importScript('User:Kaniivel/RefConsolidate_start.js');
If you are looking for ways to pull citations defined at Wikidata into Wikipedia, the English Wikipedia has an (still experimental) implementation for this named Template:cite Q.
--Matthiaspaul (talk) 17:36, 25 November 2020 (UTC)[reply]
hmmm seems like a solution; but i'd need to use it first to see if it fits. BTW this need more advertisement, never saw this before on the citation and reference help pages. TRANSviada (talk) 18:47, 8 December 2020 (UTC)[reply]
  • This working well would be conditional on some easy way to expand (without needing to jump to and from paragraph to bottom of source text) - either all refs or individual refs. 81.140.68.252 20:44, 9 December 2020 (UTC)[reply]
  • FYI: w:Help:List-defined references.--BoldLuis (talk) 13:29, 11 December 2020 (UTC)[reply]
  • I agree that systematically using list-defined references with the reflist template is the cleanest way to introduce references in a page without cluttering the wiki code. However, too many contributors do not use, or do not know, this way to proceed. So, even if a page was first created with a clean references system from the beginning, it rapidly evolves to a less ordered situation and the entropy in the wiki code increases. Most of the pages of Wikipedia are affected because there exist many ways to introduce the references and that their direct insertion in the text of the wiki code is still the preferred, or the most popular, option today. What is lacking is an uniform and systematic approach for inserting the references (with a template or as a simple text, it is not the problem) at the end of the page, below the wiki code. Implementing a feature in the visual editor (VE) to do that is a very first necessary, but also a mandatory, step. But a reliable and robust tool to progressively clean the wiki code of the existing pages automatically (a bot), manually (a script in the user preferences) or semi-automatically (a piloted bot) would be welcome. Anyway, it also requires both a change in editing habits for those directly editing the code, and also a change in the visual editor. Without a change in the visual editor it will not be possible to improve the situation. The very first objective is to have a clean wiki code on the page and a tool to clean the code in a reliable way. The centralized management of references on Wikipedia or Wikidata is still another question. It will be better to adopt a stepwise approach than to reject a too ambitious proposal. Modest improvements, step by step, would already have a high added value. Shinkolobwe (talk) 11:37, 17 December 2020 (UTC)[reply]

Voting

Hide native language codes from references

  • Problem: When e.g. automatically generating references from URL or ISBN the language code is added automatically, and is often identical to the native wikipedia language. In that case e.g. (nl) is still displayed as a prefix in the reference in the w:nl: Wikipedia, which is annoying for the reader.
  • Who would benefit: The writer is not supposed to remove redundant language codes, references can be easily copied to other language Wikipedias, the reader is never overloaded with unnecessary reference language prefixes.
  • Proposed solution: Conditionally show the language prefix: filter all matching codes, and show only "non-native" language codes, e.g. (en) and (fr) for w:nl:, so hiding (nl)
  • More comments: Folding should be applied; same i.e. language code "nl_be" etc. would match "nl"
  • Phabricator tickets:
  • Proposer: Geert Van Pamel (WMBE) (talk) 21:08, 19 November 2020 (UTC)[reply]

Discussion

TL;DR: Can be done with using {{PAGELANGUAGE}} in the template and hide the language if there is a match.
When automatically generating references, both in VisualEditor and the source editor, templates are used. In VisualEditor these are specifed on MediaWiki:Citoid-template-type-map.json, in the source editor that is usually via RefTools, in MediaWiki:RefToolbarConfig.js. On nl.wikipedia it would be a matter of editing the "Citeer boek" and other cite templates which support ISBN or URL like the TL;DR in my comment states. If anything, this lengthy explaination makes the solution seem more complicated than it is.--Snaevar (talk) 16:28, 20 November 2020 (UTC)[reply]

This is already done on English Wikipedia citations. Update your citation modules. :) --Izno (talk) 15:18, 11 December 2020 (UTC)[reply]

Note: "nl_be" isn't a valid language code; it would be "nl-BE".  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:16, 15 December 2020 (UTC)[reply]

Voting

Allow editors to identify the specific text that is supported by a citation

  • Problem: Citations are normally added at the end of a block of text, such as a paragraph. The text may be supported by the cite when initially written, but later editors commonly add new unsourced material within the paragraph without any concern as to whether the modified text still matches the source. Similarly, an initially-unsourced paragraph may later have a sourced sentence added to the end. In either case, there's no way for a reader looking at text with a terminal citation to know which parts are supported. All of it? Maybe just the last sentence? Or perhaps just some unspecified parts of the text?
  • Who would benefit: Editors and readers who value precise citations.
  • Proposed solution: Provide an easy-to-use mechanism for VE editors to indicate the exact text that a citation supports. This could be done by allowing the editor to select a range of text before adding the cite. The selected text should always remain linked to the cite, even if broken up into text fragments by a later edit, or separated from the reference by a later interpolation. Also needed is some way of displaying to a reader the text that the citation supports, for example by hovering over the reference.
  • More comments : There is a template called Ref supports2 that allows supported text to be identified in the source editor, but it's very rarely-seen - probably due to the fact that it's difficult to use and makes the source text almost unreadable.
One issue to be considered is how any such VE edit should be handled when viewed in the source editor. If all the necessary markup is made visible by default, as with Ref supports2, the source view would become very complicated. Options might include not showing or allowing use of the new feature there at all (essentially making it VE only), or hiding the additional markup by default and having a toggle button to make it visible when required. A nice implemention would allow VE editors to indicate exactly what is supported every time they add a new citation with just a single swipe of the mouse or a few keystrokes; and without impacting in any way on uninterested VE or source editors who can continue to edit exactly as before. But we have to leave implementation details to the programmers.

Discussion

  • Is it en:Template:Ref supports2 that you're thinking of? That never really caught on; the problem was that although it made it easier to illustrate exactly what statement was supported by which citation, it made the source editor edit window utterly incomprehensible. (See reference 5 on en:British Polio Fellowship—hovering over the reference does indeed make it clear that the reference is supporting the statement "as a self-help and mutual aid society for those affected by polio", but at the cost of doubling the length of the reference.) Iridescent (talk) 15:56, 19 November 2020 (UTC)[reply]
Thank you, yes that was what I'd seen. But I agree that that solution is not at all user-friendly in the source editor. I've amended the proposal to discuss the existing template. MichaelMaggs (talk) 14:40, 20 November 2020 (UTC)[reply]
Another big problem is that once you wrap a whole sentence in a template it becomes much harder to edit in the visual editor. ESanders (WMF) (talk) 12:33, 30 November 2020 (UTC)[reply]
Indeed. Another reason why the existing situation is not good. MichaelMaggs (talk) 09:27, 9 December 2020 (UTC)[reply]
  • There is an issue here, but it is wrong to assume that all additions after the reference is added aren't using the same reference. Frankly, VE editors don't add many refs in the first place. What if multiple refs support the same text? Johnbod (talk) 19:27, 20 November 2020 (UTC)[reply]
The same text supported by several references would be selected several times. Don't see any problem with that. MichaelMaggs (talk) 21:51, 20 November 2020 (UTC)[reply]
  • Another approach to this problem (looking at it from a different angle) is to use the |quote= parameter (and friends like |script-quote=, |trans-quote=, and |quote-page(s)=) of the CS1/CS2 citation templates (in the English Wikipedia), and provide an excerpt of the relevant section of the cited source supporting the statement in the article. That is, not duplicate the (ever changing) article prose in a template parameter but cite the original prose from the source. Depending on the circumstances, this may be more or less suitable than the other way around. --Matthiaspaul (talk) 12:04, 11 December 2020 (UTC)[reply]
I do this fairly frequently, also because the cited source could be changed or break in the future. — Alexis Jazz (talk or ping me) 12:24, 11 December 2020 (UTC)[reply]
In some cases, specifying verbally might work better: own essay, but en:WP:Contort the citations on how to describe the info you are citing in a citation if needed. Admittedly this won't help those editors who carelessly insert uncited text before a cite without a cn tag. HLHJ (talk) 23:27, 19 December 2020 (UTC)[reply]
  • This is basically a type of annotation. Annotation support would be super useful. Unfortunately, also super hard. --Tgr (talk) 07:03, 14 December 2020 (UTC)[reply]
    I would love to see a generalised Annotation service as a separate Wikimedia project. But, yes, very hard especially if you want to annotate third-party pages that you don't control and which could change unpredictably. Core content like references needs to be stored with the page revision, though. Pelagic (talk) 03:10, 16 December 2020 (UTC)[reply]
  • Markup could be doable by building on named references. Let's say you introduced an extension element <refd> or <refby> for "referenced by". Then you could have <refby name=one><refby name=two>The sky is blue.</refby> <refby name=three>And the sun is hot.</refby></refby> Hooking up the plumbing for reference popups, etc. would be another matter. Pelagic (talk) 03:28, 16 December 2020 (UTC)[reply]
    Of course, someone would lay a template on top of that so that you could write it more succincly as {{refby|two|The sky is blue.}}...etc., avoiding the "name=" and "/refby". But templated markup would behave differently under VE than tagged markup. Pelagic (talk) 03:37, 16 December 2020 (UTC)[reply]
    A span tag for references, similar to, say en:Template:Failed verification span. That's more readably structured than Template:Ref supports2, but still not optimal. Making a new ref template would be easy to do; design proposals? HLHJ (talk) 23:27, 19 December 2020 (UTC)[reply]
  • I agree in principle that clearly indicating the semantic link between citation and supported text is good. I'm not sure how best to do this. HLHJ (talk) 23:27, 19 December 2020 (UTC)[reply]
  • [Added after the survey was closed] While the survey is long closed, I think it might be worth noting that a "context section" feature has been recently added by me to the r citation template in the English Wikipedia. Among many other things it allows to define a (possible non-continuous) section in the same way as with ref supports2 and will display this as a tooltip when hovering with the mouse over the superscript link where the citation was invoked. The name of the context section can be given as a parameter value, but by default the template will derive a (practically) unique name itself from the name=, group= and various in-source-location parameters. Using CSS, it might be possible to further improve this in the future so that the marked text in the article gets highlighted when hovering over the reference link.
Since it was mentioned elsewhere inhere as well that annotations would be a desirable feature to have, I'd like to mention that r also implements some kind of annotation system now to define various kinds of annotations (page numbers, quotations, other commentary, sub-references or even other citations) as part of the citation template's invocation, and the template will display parts of this information in form of a tooltip when hovering over the reference link and optionally also combine it into the full citation defined elsewhere where it will be appended at the end of the original definition.
While both features aren't exactly what was asked for in this thread, they still might be useful for some. --Matthiaspaul (talk) 15:06, 24 September 2021 (UTC)[reply]

Voting

Thanks for the long-term support :) Making the source text more complex is currently the only editing option. The proposal explicitly aims to get away from that. MichaelMaggs (talk) 09:23, 9 December 2020 (UTC)[reply]

Re-use citations with changed page number in visual editor

  • Problem: In visual editor, there is no simple way how to copy (re-use) existing citation and only change a page number in it. Instead, one is forced to fill the citation form again (with all but one parameters the same) which is annoying.
  • Who would benefit: All editors using visual editor. Power users will save a lot of time. New users will not be in danger to use the current re-use function in a wrong way (re-using a citation, changing a page number and not knowing that the page number is now changed in the first appearance as well).
  • Proposed solution: In "Add a citation" dialog, there are three options: Automatic, Manual and Re-use. Within a Re-use option, there is a list of current citations. There should be additional options: re-use without changes and re-use with changes (maybe better wording needed). The first option will copy the citation and close the dialog, the latter will open a dialog with the filled cite template, allowing to change any parameter (the Page(s) cited parameter could be pre-selected) and insert as a new citation.
  • More comments:
  • Phabricator tickets: T96536
  • Proposer: Vojtěch Veselý (talk) 03:40, 18 November 2020 (UTC)[reply]

Discussion

  • This is being worked by book referencing design by WMDE on a parallel path (particularly phab:T245299) and is accordingly probably out of scope for CommTech. (And the task you linked should probably be closed or retargeted.) --Izno (talk) 05:12, 18 November 2020 (UTC)[reply]
  • This is not relevant just for the special case of changing a page number, which can indeed be addressed by other means in some circumstances. This problem also exists when I want to create any similar reference, e.g. an article cites from several articles in the same online newspaper, but the automatic citation generator is so wrong with this particular source (such as choosing the wrong citation template), that it is much easier for me to copy and modify another existing reference (pointing to another article but in the same source) already present in the same article. --Blahma (talk) 22:05, 18 November 2020 (UTC)[reply]
    I might buy that use case. (If there is a source that is having issues with the auto generator, that should be a bug filed for upstream.) --Izno (talk) 17:26, 20 November 2020 (UTC)[reply]
  • @Vojtěch Veselý: I think this is just a great idea ! I have also often had this problem. We could stop wasting user time copying by hand all the book details for just adding a different page ! --Jurbop (talk) 16:34, 30 November 2020 (UTC)[reply]
  • I guess this feature will be much easier to be implemented (and to be used) as soon as #Structuring of individual references is available, because with the latter there is no further need to copy whole citations just because of different page numbers. BR --Bicycle Tourer (talk) 16:46, 20 December 2020 (UTC)[reply]

Voting

@Ponor: Thanks for the link. For me, the long term solution is just some template with ID (and perhaps parametr "page number") and the rest of the data store on Wikidata (here is nice presentation on this issue). My proposal is just small update/patch. --Vojtěch Veselý (talk) 11:30, 10 December 2020 (UTC)[reply]

Allow customizing of Citoid/RefToolbar output

Discussion

Voting

Integrate Template:Sfn into the visual editor

  • Problem: w:Template:Sfn is not supported by the visual editor; therefore, it is hard to edit articles written with this template for users who write in the visual editor.
  • Who would benefit: Users who prefer visual editor, readers who want to check references in bigger articles.
  • Proposed solution: Add the support of Template:Sfn and all the linked templates in the other language versions. I could imagine that references would be easily added with a tool, just by selecting an item from Bibliography and specifying pages.
  • More comments: Feel free to rephrase my suggestion as I am not a native English speaker.
  • Phabricator tickets:
  • Proposer: PuchaczTrado (talk) 12:45, 17 November 2020 (UTC)[reply]

Discussion

  • Yes! This is my number one reason now for not working almost entirely in VE. MichaelMaggs (talk) 15:14, 18 November 2020 (UTC)[reply]
  • Can someone please clarify steps to reproduce the problem? When I go to this en.WP article in VE and click on footnote 1, I get a dialog that allows me to edit the sfn template behind that footnote number. It looks OK to me, but I do not use VE except for testing. Jonesey95 (talk) 15:38, 18 November 2020 (UTC)[reply]
    In VE, try to set up a new sfn citation by clicking on the Cite button. I don't think it's possible. In contrast with a standard citation, an entirely new sfn reference needs a separate bibilography entry to link to, which can't easily be done in VE. Though, as you say, once a cite is there, it can be edited. MichaelMaggs (talk) 16:14, 18 November 2020 (UTC)[reply]
    I see what is happening. To insert an sfn template in VE, it looks like you need to go to Insert - Template and type sfn. It should work fine that way. So it looks like you are asking developers specifically to allow the insertion and re-use of sfn templates using the Cite button in the VE toolbar. If so (or if not), someone may want to clarify the problem description before voting starts, otherwise you will probably get a bunch of comments similar to this one. Jonesey95 (talk) 03:24, 19 November 2020 (UTC)[reply]
  • I think you're waiting for book referencing to be finished by WMDE (particularly phab:T245299) and is accordingly probably out of scope for CommTech. --Izno (talk) 17:27, 20 November 2020 (UTC)[reply]
  • Yes, this is such a huge inconvenience. I'm not familiar with the WMDE task, but any way to make it easier to work with sub-references in general and in VE specifically is very much needed. It would make editing so much easier for experienced editors and would help many inexperienced editors understand the importance of sub-referencing. Ergo Sum (talk) 04:04, 1 December 2020 (UTC)[reply]
  • FYI: Template:Sfn. BoldLuis (talk) 11:29, 11 December 2020 (UTC)[reply]
  • Honestly, I don’t add images, so personally, no problem if you delete picture icon and replace it with sfn icon on the toolbar, if merging sfn under [”] icon is a resource eater. FYI instead of changing between wikitext and VE modes, on VE I enter {{ then "Sfn" in the box so that system offers me sfn input form. Maybe I trained myself too much and forgot we could have it on the VE toolbar, which, as mentioned on this page, will encourage citation page number to be specified. Reliability is what this request will help us fulfill. --Omotecho (talk) 21:38, 18 December 2020 (UTC)[reply]

Voting

Globalize CS1

  • Problem: Module CS1 suite is currently maintained in EnWiki even though it's de facto used worldwide for citations. Keeping track of changes is difficult and this makes the continuous update process needed to run it pretty difficult in different wikis, especially small ones.
  • Who would benefit: All wikis, especially small ones.
  • Proposed solution: Globalize module CS1. Find a way to track updates in different Wikis, notify them when new updates are available and help them do the updates when they're available.
  • More comments: Elaborated in detail here.
  • Phabricator tickets:
  • Proposer: Klein Muçi (talk) 09:19, 20 November 2020 (UTC)[reply]

Discussion

@Pigsonthewing: Thank you for that! Actually I am aware of that or even of the phab tasks of producing global modules. But the problem, as everyone knows, is that they're not progressing much as projects. If you read my original post (in More comments), you'll see that I propose another approach to handle this situation: We create a big dynamic table on here (Meta) that we use to keep track of all the Wikis that use the said module and how updated is their version of it compared to the default one. (Maybe we can name updates.) The table would also include specific wishes or changes they wish to make to the their version of the module compared with the default version of it (The EnWiki one). Then every time the default one gets updated, wikis are notified en masse in their village pumps automatically by Mediawiki Message Delivery, describing what has changed and what they need to do to "get the update". Some volunteers also get mentioned who said users can contact for help in their updating process. If things go well, we can have global bots to help us in this process. To keep the dynamic table updated and maybe even to help globally on the update of some pages of the module that don't need much change and could be handled in a copy-paste manner. The said module also has its maintenance, property and error categories and its help pages. A lot of small Wikis don't know how to actually solve the problems with pages that get sorted in these categories. This could be handled the same way as the update process I mentioned above. Some global bots could help solve some easy problems (I already have one doing that on SqWiki and SqQuote), some volunteers could set themselves up as contacts to help small Wikis solve them... All this process is sort of already happening, it's just that it's happening on EnWiki and the only volunteer helping is Trappist. I think if it (this process) could be Metafied, (what I described above and more or other ideas other people might have) it would provide an easier global infrastructure. I'm already ready to help to set something like this up but only me and Trappist can't really deal with just the information gathering to create the said table, let alone maintain it and help keep the whole process up to date. So we either need more volunteers willing to participate in this idea, or more technical ideas how to automatize tasks needed for a process like this. - Klein Muçi (talk) 21:23, 26 November 2020 (UTC)[reply]
Klein Muçi:
  1. If you like the Global templates idea, please express your support at mw:Global templates/Discuss :)
  2. If I understand your suggestion correctly, a thing like what you suggest already exists at mw:Multilingual Templates and Modules, with the DiBabel tool. User:Yurik can say much more about that.
  3. Another thing in the community wishlist that can help is Community Wishlist Survey 2021/Miscellaneous/Templates translation.
Hope it helps :) --Amir E. Aharoni (talk) 08:45, 27 November 2020 (UTC)[reply]
@Amire80:, thank you!
  1. I did.
  2. From what I saw at the MW page, it does look like it dabbles with the same idea I'm talking about. But given that it is the first time I encounter that page (or that tool/bot), I'd really like some more in-depth explanations about it. I hope Yurik can help, even though I sort of believe the aforementioned conversation would be better held between Yurik and Trappist the monk to settle if the tool can somehow help with module CS1.
  3. Yes, I think I'll show my support even to that idea. Even though it deals mostly with templates and I think it reaches my idea tangentially, I support everything that helps internationalization of templates and modules. I do believe CTT is really a powerful tool (thank you) and can be helpful in different ways. Actually, I've writen you on EnWiki in the past about it and the idea of extending its function to integrate some mw:Extension:BoilerRoom logic to be helpful for us in SqQuote, but I didn't get an answer. - Klein Muçi (talk) 11:41, 27 November 2020 (UTC)[reply]
Klein Muçi, so sorry I haven't replied to you on my talk page earlier! I replied now. --Amir E. Aharoni (talk) 12:39, 27 November 2020 (UTC)[reply]

Voting

Configurable order of references in references section

  • Problem: At present references are (numbered and) listed in the order of their invocation in an article. While this is a reasonable default, it would sometimes be useful to list the references according to different sort orders, f.e. chronologically or alphabetically
  • Who would benefit: All readers of articles where the default order is not the preferable one
  • Proposed solution: Add some option like an order= attribute to <references/> wiki markup (and/or a |order= parameter to templates such as Template:Reflist) to define one of the following display orders (the first two are the most important ones, the others are provided to illustrate how this model could be further extended):
  • "Invocation" (default or <references order="invocation">): Order of invocation in article.
  • "Natural" (<references order="natural">): Order of occurence in <references>...</references> sections (or in Template:Reflist |refs=...). Provided that the list of references in there is manually sorted by, f.e., author name or date, this would allow for reference lists to be sorted by name or date (or any other arbitrary order) even if the order of invocation in the article is different.
  • "Reference-ID-ascending" (<references order="id-ascending">): Order in alphanumerical ascending order of the ID values of the <ref name="id">...</ref> attributes in references. Refs without name= would be appended at the end of the list per default "invocation" order above.
  • "Reference-ID-descending" (<references order="id-descending">): Order in alphanumerical descending order of the ID values of the <ref name="id">...</ref> attributes in references. Refs without name= would be appended at the end of the list per default "invocation" order above.
  • "User-defined" (<references order="number-ascending">): Ascending order per numerical argument n (0..999) in <ref order="n">...</ref>; refs without order= would be appended at the end of the list per default "invocation" order above.
  • "Author-ascending" (<references order="name-ascending"): Ascending order per non-numerical string argument name in <ref order="name">...</ref>; refs without order= would be appended at the end of the list per default "invocation" order above.
  • "Date-ascending" (<references order="date-ascending"): Ascending order per ISO 8601 argument date (in "yyyy[-mm[-dd]]" format) in <ref order="date">...</ref>; refs without order= would be appended at the end of the list per default "invocation" order above.
  • "Date-descending" (<references order="date-descending"): Decending order per ISO 8601 argument date (in "yyyy[-mm[-dd]]" format) in <ref order="date">...</ref>; refs without order= would be appended at the end of the list per default "invocation" order above.
  • More comments:
  • In the examples above it is assumed that the implementation could distinguish the three types of <ref order="...">...</ref> attributes (numbers, name strings and ISO 8601 dates) automatically and that references with attribute types not selected as sort keys per <references order="..." would be appended to the list. It would be possible to modify/extend this model in various ways, f.e. to have different attributes for the different types, or to allow sorting of the remaining references according to secondary sort keys.
  • The proposal above works on the level of wiki markup (rather than on template level) in order to remain independent of citation template implementation details in the various Wikipedia entities. It might be possible to achieve similar reference sorting on higher levels, but it would probably require client-sided scripting (Javascript) then and therefore would not be universal.
  • Nevertheless, it would be desirable to have some means to pass name, date or reference-id information from citation templates like CS1/CS2 to <ref></ref> markup. This would allow to provide a name or date in the citation template without having to repeat this information in the <ref name/order=></ref> argument. No such communication model seems to exist at present, but would certainly be desirable to have also for many other purposes. Article-wide variables come to my mind. Perhaps some new kind of strip-markers? (TBD.) Another possible solution could be to change the citation templates to emit the <ref order=...></ref> markup themselves or to create a wrapper template for this.

Discussion

  • I can understand the desire to add sorting options to the references. However, ultimately the order should be controllable by the user in their settings and not what article editors prefer. Thus, I can only fully support this if the user has final say on the ordering based on their preference. RedWolf (talk) 19:33, 10 December 2020 (UTC)[reply]
Yeah, I too wish all such configuration settings could be controlled by settings in user preferences, and the scheme certainly could be further extended to provide this in the future. However, at present, the functionality to sort the reference list does not exist at all, so it seems to be desirable to first have this implemented as basic functionality and propose more user configurability in the next round.
--Matthiaspaul (talk) 21:11, 10 December 2020 (UTC)[reply]
  • I think this would only be really useful if it reached the stage where readers can sort the references by lots of different attributes. The proposer hints at some of the difficulties we would have in making this tool useful, which would entail citation templates (like {{cite book}} on the English Wikipedia) being able to pass data to the "ref" attributes. The tool will not be very successful if editors need to manually add all the data twice per reference on a per-page basis (which will also double the wikitext length). It's a good idea and would be useful to readers and also editors (I could find typos in refs I write faster if they're sortable) but I do wonder how big a project this would be. — Bilorv (talk) 01:34, 11 December 2020 (UTC)[reply]
That's one of the reasons why I wrote that the first two examples are the most important ones, as these ones work without having to provide additional arguments. In the example #2 (what I called "Natural" sort order), all the editor would have to do is to manually provide the list-defined citations in the <references>...</references> block in the desired order (whatever that is, alphabetically, chronologically, or whatever else), as it already happens in ==Bibliography== or ==Works== sections most of the time, and the references would be listed in this order (instead of in the order of invocation). This is the core functionality, that would be needed to be implemented, and it would give editors full control over the display order of references without having to add or duplicate any extra arguments.
The other examples further down are already kind of "icing on the cake", as they would provide predefined display sort orders even for unsorted reference lists (or lists in yet another order). Among them, the proposed sort orders "Reference-ID-ascending" and "Reference-ID-descending" would draw on the name= attribute already present in most citations, f.e. <ref name="xyz">...</ref>. As the xyz in there most often is a string in the form "name-year" by convention this is already a good value to sort for, and one which still would not need any additional attribute to be given or additional citation information to be duplicated.
Only in the example cases #5 to #8 (starting with "User-defined"), we would actually need a new attribute like <ref name="xyz" order="abc">...</ref>, which could be any free text to sort for, but could also duplicate values given as parameter values in citation templates (if citation templates are used inside the <ref>...</ref> block at all). I agree, it would be neat if there would be a way to pass the arguments of template parameters like for the author name or publication date into the order= attribute automatically somehow, but even if editors would have to do this manually (as they sort-of-do with the name= attribute all the time already), it would be an acceptable optional overhead, not duplicating the length of citations. As template developers have been creative in the past, I envision that once the basic reference sorting functionality would become available, template developers would soon develop wrapper templates for this so that even this inconvenience would be eliminated for citation template users.
--Matthiaspaul (talk) 13:05, 11 December 2020 (UTC)[reply]
  • I'm hoping sorting would be automatic based on criteria specified in a separate template or in the {{reflist}} itself (i.e. {{reflist}} controls whether sorting is alphabetical by title, chronological by source date, etc.), rather than based on a switch in each ref tag. I foresee stupid edit wars over which references appear first, likely trying to move sources an editor wants to promote higher in the sort order, or editors preferentially sorting references based on their POV. I do like the concept, though - ref sorting by invocation order does seem to lead to editors (for the same reasons) overloading an article's lede with preferential sources so that they appear higher in the reflist. Ivanvector (talk) 14:18, 11 December 2020 (UTC)[reply]
While I would appreciate this as well, I'm afraid this is technically impossible to implement. Templates cannot influence anything outside themselves, unfortunately. That's one of the reasons why my proposal is based on the level of the underlying wiki markup rather than on template level.
What would be possible for a template like {{reflist}} is to pass down an argument to control the sort order, so that something like:
{{reflist |order="natural" |refs=
<ref name="R1">{{cite book |...}}</ref>
<ref name="R2">{{cite book |...}}</ref>
...
}}
would internally issue something like:
<references order="natural">
<ref name="R1">{{cite book |...}}</ref>
<ref name="R2">{{cite book |...}}</ref>
...
</references>
The name="xyz" thing would be unnecessary for sort orders "Invocation" and "Natural" (but required for list-defined references, anyway), but it would be required for sort orders "Reference-ID-ascending" and "Reference-ID-descending". It would also be optional for the other four proposed sort orders which would require order="abc" instead.
Without any such "hint", MediaWiki's Cite extension (the code which would have to be modified to implement this sorting functionality) has no way of knowing a citation's sort weight as it cannot read template parameters (this would be nice to have, but is a fundamental design limitation that AFAICS could only be had through a complete redesign and rewrite of the underlying software - which is unrealistic to happen).
The proposed scheme, however, is universal, that is, it would work regardless of how citations are implemented in a particular wiki (and if this is based on templates or not), and I estimate that it would not require more than a couple of days to code, therefore, it is quite realistic to be actually implemented by the team given enough community support.
--Matthiaspaul (talk) 17:22, 11 December 2020 (UTC)[reply]
  • I have long longed for functionality like this for well-developed articles. However, I think the proposed functionality is far richer than necessary. All that's needed is the "Natural" functionality listed above, and since the current function is to put things in an essentially uncontrollable, random order, there can be no objection to simply making "Natural" the new default -- no need to invoke it somehow, no need for the new any new syntax and the extensive options proposed above. A simple implementation would be to for the machinery to parse the refs defined in {reflist | refs=} first -- before parsing any refs defined in the article text proper. This way, refs defined within the {reflist |refs=} will get assigned "reference numbers" in the order they appear there (not the order they appear in the article) and will be output in that order. (As Matthispaul points out, this allows the refs to be placed in any order editors want, manually, without any fussing about sort orders, date formats, syntax, etc etc etc. Few articles have enough refs to make automatic ordering a big convenience.) Ideally, the refs in the {reflist |refs=} will be the only refs there are at all; however, if there are any stray refs defined in the article proper (or if editors haven't bothered to use {reflist |refs=}) then any refs defined in the article get parsed last, after all the refs in {reflist |refs=}; so they'll get the highest "reference numbers" and be output last. Thus all refs do get output no matter what; and if editors wish to control their order by listing them in {reflist |refs=} they can, and if they don't want to bother doing that then everything works just like it does now. EEng (talk) 14:39, 11 December 2020 (UTC)[reply]
I see your point, however, replacing the current sort order by "Natural", there will be editors who will miss references sorted by "Invocation" order (while other sort orders are desirable at times, it is not that the default "invocation" order would not be desirable as well in many articles - you see them as "random" and "undesirable", but I doubt the majority of readers would agree with this). While "Natural" would allow editors to sort the references in the references block according to the invocation order as well (and thereby can be seen as providing a superset of possible output orders), it would require more maintenance to keep the listed references in the same order as the order of invocation.
So, if we were pressed to have only one hardwired sort order, "Natural" would certainly be a better option than "Invocation", and I would support this as well. (In my proposal, I kept "Invocation" as the default for backward compatibility - not all users would want for the sort order to suddenly change to "Natural" all over the place without first changing the order of references in the list.) However, I think, that while we are here already, the overhead to make this configurable (at least for the two important sort orders #1 and #2) is minimal, and at least for the first few proposed sort orders all that would be required to get a "Natural" sort order would be to add some order="natural" attribute/parameter. Hardly unbearable.
The other proposed sort orders are "icing on the cake". I provided them to illustrate how this scheme could be extended if the developers have enough time for it, but I would also be happy if the developers would just implement the first two (or first four) sort orders. The good thing is that this could be implemented in steps, adding more sophistication over time.
--Matthiaspaul (talk) 18:22, 11 December 2020 (UTC)[reply]
An elegant approach for where list-defined refs are used, @EEng. Pelagic (talk) 04:47, 16 December 2020 (UTC)[reply]

I would like for the reader to be able to sort references similar to how they can sort wikitables. Setting a sort order in wikitext will lead to fights. I've been slapped down before for sorting list-defined refs the "wrong way", and that ordering wasn't even reader-facing. Currently the rendered HTML is structured like <li id="cite_note-18"><span class="mw-cite-backlink">...</span> <span class="reference-text"><cite id="..." class="citation book cs1">...</span></li>. Could we add some attributes (date, authkey) to the top-level <li> and use client-side Javascript to manipulate the DOM and sort the list items by attribute? —Pelagic (talk) 04:30, 16 December 2020 (UTC)[reply]

Cite template could add a <sortkeys date=2020-12-16 authkey=smith /> element inside the <ref> tags, then server-side processing could copy those attributes onto the generated <li>. Pelagic (talk) 04:39, 16 December 2020 (UTC)[reply]

Voting

It's not so much as to not find a reference, more to have similar references grouped together. For example, an author might have published multiple works in a year, and it might be desireable for the reader to be immediately pointed to the other publications while reading one of them. Similar, studying one reference, it might be highly desirable to find other related works published shortly before or after the date of publication. If you check reference lists in publications, they are often sorted alphabetically or chronologically (or by other keys or methods), while, at present, in Wikipedia they are listed in the order of their invocation, which might look almost "random" if only looking at the list of references.
Yet another case were it might be helpful to have the references sorted by some key is in PDF exports or printed articles, where "clicking on a link" is not available as a means to find a reference in the list.
--Matthiaspaul (talk) 21:11, 10 December 2020 (UTC)[reply]
Unfortunately, you misunderstood the idea in various ways. My proposal does not rely on ISO date formatting and has nothing at all to do with automated date formatting or even the output format of dates.
I used the ISO date format in the last two of the examples ("Date-ascending" and "Date-descending") to illustrate possible extensions to the requested basic functionality ("Invocation" and "Natural"). These two examples are entirely optional (as has been pointed out several times). They could just as well use any other date format of choice (or none at all), however, as this whole proposal works on markup level and one of the goals is to be universal, machine-readable and independent of any configuration differences in the various Wikipedia entities, the international date format per ISO 8601 is a quite natural choice. Also, no style guide forbids to use ISO 8601 dates on source code level, only for (some) display purposes - after all, it's just an argument to an attribute. Further, the proposal has nothing to do with the display of dates; the dates in whatever format are just given on source code level as sort weights and never displayed anywhere - dates used for display purposes are defined in the citation itself - which has nothing to do with the date in the proposed order= attribute of the surrounding <ref></ref> block.
So, if you don't like ISO dates, just ignore the last two examples or think of them as if they were using a date format of your preference. After all, the description is to "transport the message" and illustrate how a realistic example implementation could look like, the decision on the actual attribute names and detail syntax remains up to the implementors.
--Matthiaspaul (talk) 23:15, 15 December 2020 (UTC)[reply]
  • Support Support for user-side sorting. Uanfala (talk) 22:53, 19 December 2020 (UTC)[reply]
  • Support Support I support that idea, but there should be clear and strich rules as to when to use that function and when not. Using the function should not be a matter of taste or individual preferences, and the risk of conflicts must be reduced to the minimum. Nachtbold (talk) 12:21, 21 December 2020 (UTC)[reply]
  • Question: Sorry, what are we supporting or opposing? If it's the general idea of replacing the current chaos-order with something else, sure. If it's the rococo orgy of options proposed by Matthiaspaul, then No, because that's never going to get done and even if it did it would just bloat new editors' learning curve for no reason at all -- no one's going to use all that COBOL-like crap. Neither does the reader need to be able to change the order. In all humility, my proposal to simply parse {reflist|refs=} first is amazingly simple, gives editors complete control, and might actually get done before all of us have gone to meet our Maker. The idea that there will be editors who will miss references sorted by "Invocation" is just (sorry) absurd -- since a new reference can be inserted by anyone at any point at any moment, "Invocation" order is no order at all -- there's nothing to miss unless you like chaos. EEng (talk) 14:57, 24 September 2021 (UTC)[reply]

Structuring of individual references

We should know how to add a reference to a text and how it appears at the end of an article! I don't know exactly how it works! (Machine translation from German.)

Discussion

Fixed Link to project page --Bicycle Tourer (talk) 19:43, 26 November 2020 (UTC)[reply]

Activation of this feature will finish repeated discussions about how to abbreviate similar citations with only small differences, e.g. different page numbers. Today authors are inventing special mechanisms using template:anchor, which will be very difficult to maintain in future. Thes feature could probably include a solution to the requested new feature "Re-use citations with changed page number in visual editor". It is esp. useful for power editors, who create long articles. BR --Bicycle Tourer (talk) 19:43, 26 November 2020 (UTC)[reply]

The feature is independent from VE. It allows to group different references (e.g. different page-number) of the same source, and by this there is no need to copy and paste the whole source for every reference (I guess your "it's easy" means copy and paste) BR --Bicycle Tourer (talk) 20:59, 10 December 2020 (UTC)[reply]
  • As far as I understand this request, this is an extension already been worked on by WMDE under the title "Book referencing" since some while. It was planned to be released in 2020, now postponed to 2021: [1]
--Matthiaspaul (talk) 21:38, 10 December 2020 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Citations&oldid=20877418"