Community Wishlist Survey 2021/Citations

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Citations
14 proposals, 43 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!



Save citations when translating

Edit proposal/discussion

  • Problem: When I'm translating an article in the wikipedia translation page and I save my work and close the page before publishing, all my references get lost and the page only displays a message that says something like "the content is in another source", then when I look into the "references" section, it's all blank, so I have to errase all the citations and write them again.
  • Who would benefit: Translators and editors
  • Proposed solution: Save the references in the same format that the article is written so they don't get lost when saving before publishing. I don't know much about programming so excuse me if I don´t give a better proposal.
  • More comments: It's a problem that only arises if the translation is saved and the page closed before publishing. When publishing the article before saving and closing, references stay fine.
  • Phabricator tickets:
  • Proposer: Braulio rs (talk) 00:48, 27 November 2020 (UTC)

Discussion

  • @Pginer:, I think this will interest you. Braulio, there are a lot of different issues with references in the ContentTranslation tool (see tracker in [1]). It will be helpful if you can give specific examples to identify when is still causing trouble.--FAR (talk) 11:16, 29 November 2020 (UTC)

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

Edit proposal/discussion

  • 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.
  • Phabricator tickets:
  • Proposer: MichaelMaggs (talk) 17:16, 18 November 2020 (UTC)

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)
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)
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)
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)
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)

Convert tools for different citations or citation styles

Edit proposal/discussion

  • 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)

Discussion

  • @Piotrus: To which wiki does this pertain ? As citation/reference templates all diffeer per wiki. —TheDJ (talkcontribs) 11:27, 17 November 2020 (UTC)
    Slightly less an issue because Parsoid/TemplateData tie templates together I think? --Izno (talk) 18:34, 17 November 2020 (UTC)
  • Regarding Harvard versus APA, that might be something for a specific coder to make a module for. We had an experiment for MLA books on Wikipedia convoluted with the current Citation modules but it was definitely just a trial, and made that module very spaghetti. But having a module/template would probably be the easiest way to do something--it's just no-one has said (very loudly) that they want it. --Izno (talk) 18:34, 17 November 2020 (UTC)
  • @Saung Tadashi: I've redirected your proposal here, per our discussion (that's basically what I meant by "merge"). Kind regards, MusikAnimal (WMF) (talk) 03:47, 2 December 2020 (UTC)
    @MusikAnimal (WMF): Thank you, MusikAnimal (WMF) :) Saung Tadashi (talk) 04:19, 2 December 2020 (UTC)

Allow customizing of Citoid/RefToolbar output

Edit proposal/discussion

  • Problem: Currently the RefToolbar (enwiki and equivalents on other projects) and Citoid only allow one output, <ref>{{citation template}}</ref>.
  • Who would benefit: People who use the aforementioned two tools on enwiki and other projects but don't use <ref>
  • Proposed solution: Allow the output of the tool(s) to be customized - say through a MediaWiki interface page - so that it can output other formats such as sfn (equivalents on other projects)
  • More comments:
  • Phabricator tickets:
  • Proposer: Jo-Jo Eumerus (talk, contributions) 09:58, 29 November 2020 (UTC)

Discussion

Tool for separating the references from the body text

Edit proposal/discussion

  • 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)

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)
http://josef-svoboda.site44.com/wiki/wikiref2.html JAn Dudík (talk) 20:35, 25 November 2020 (UTC)
  • 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)

Configurable order of references in references section

Edit proposal/discussion

  • 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.
  • Phabricator tickets:
  • Proposer: Matthiaspaul (talk) 01:55, 26 November 2020 (UTC)

Discussion

Allow creating bibliographic entries with the Citoid tool in VE

Edit proposal/discussion

  • 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)

Discussion

Globalize CS1

Edit proposal/discussion

  • 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)

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)
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)
@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)
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)

Hide native language codes from references

Edit proposal/discussion

  • 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)

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)

Strukturieren von Einzelnachweisen

Edit proposal/discussion

  • Problem:
  • Wem würde dieser Wunsch helfen:
  • Lösungsvorschlag:
  • Weitere Kommentare:
  • Phabricator-Tickets:
  • Antragsteller: Tsor (talk) 15:47, 26 November 2020 (UTC)

Diskussion

Im Testwiki gibt es eine eine neue Option zum Strukturieren von Einzelnachweisen, mit der man auf mehrere Stellen desselben Werkes verweisen kann.

Projektseite Tsak 100645

Bitte diese Funktion aktivieren.

Antragsteller: --Tsor (talk) 15:47, 26 November 2020 (UTC)

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

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)

Re-use citations with changed page number in visual editor

Edit proposal/discussion

  • 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)

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)
  • 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)
    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)
  • @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)

Integrate Template:Sfn into the visual editor

Edit proposal/discussion

  • Problem: 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)

Discussion

  • Yes! This is my number one reason now for not working almost entirely in VE. MichaelMaggs (talk) 15:14, 18 November 2020 (UTC)
  • 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)
    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)
    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)
  • 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)
  • 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)

Full reference in popup on hover over inline citations

Edit proposal/discussion

  • 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)

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)

  • The WMDE book referencing will support this when it rolls out. It was held up by the pandemic as I understand it and should be coming Soon. (I've been saying that a while now....) --Izno (talk) 18:16, 17 November 2020 (UTC)
    • I hope this soon is soon enough. But is this only about how the references would be formatted, or does it include inline pop-ups with all the information from the reference (+page/chapter/section information) as well? Web format is rich enough so we should never need to scroll up and down (no bookmarks, remember) to follow a citation. Ponor (talk) 05:04, 18 November 2020 (UTC)
      • The intent is all the data last I checked. --Izno (talk) 05:46, 18 November 2020 (UTC)

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)

Reference tools in the source editor

Edit proposal/discussion

  • Problem: In the French source editor (I don't know others), we can't make references automatically (with an ISBN or a Doi for example). We have to make it manually or use the visual editor. However, making it manually is time-consuming and the visual editor is too greedy on computer resources as CPU and internet speed for old computers and bad connexions.
  • Who would benefit: Contributors with old computers and bad internet connexions, as well as contributors who don't like writing with the visual editor.
  • Proposed solution: Make a lightweight reference tool in the source editor. Before the creation of the visual editor reference tool, I used to write references with this external tool : Refswikipedia by Lebronj23 (fr). But it doesn't work anymore.
  • More comments: Thank you for your work and have a good day.
  • Phabricator tickets:
  • Proposer: Abalg (talk) 09:54, 17 November 2020 (UTC) (fr:utilisateur:Abalg)

Discussion

Hello. I cannot say anything about the difficulty of implementing such a tool in the source editor. I also do not know how many people have problems using the visual editor. I stopped maintaining the tool mentioned above for ISBN and DOI notably because the visual editor is already doing a good job there. I preferred to focus on web links, where the tool really has an added value compared to the visual editor. If many people are interested, I could implement some patches to get the DOI and ISBN working again when I find some time for that. It should not be too complicated. It will not solve the problem on the long run however. Regards, --Lebronj23 (talk) 21:41, 17 November 2020 (UTC)

Can we generalize this beyond the French wikis, Abalg? Many other wikis (including English Wikiversity) do not have Citoid facilities either, which is a bit discouraging and reduces their appeal. Anywhere that Visual Editor has the tools the source editor should too. HLHJ (talk) 01:13, 24 November 2020 (UTC)
Hello HLHJ, I'm agree with you. --Abalg (talk) 01:45, 24 November 2020 (UTC)

Note that Citoid is available in the mw:2017 wikitext editor. ESanders (WMF) (talk) 13:25, 26 November 2020 (UTC)

The wikitext editor is what I name the visual editor. The problem concern only the source editor. Regards. --Abalg (talk) 13:34, 26 November 2020 (UTC)

There is en:Wikipedia:ProveIt and en:Wikipedia:RefToolbar in enwiki for old wikieditor which sounds same --Zache (talk) 16:07, 27 November 2020 (UTC)

Hello Zache, ProveIt seems to work good (I just install it and taste it). But it's not a native solution. The reftoolbar seems to be a great solution too. And a native one. Except in the French wikipedia. Do you know how can we transfer it on the French wikipedia and other languages? Regards. --Abalg (talk) 14:31, 30 November 2020 (UTC)
Technically yes, in fiwiki it is gadgets (under label testing and not supported) and it more or less works. However, there is currently some case sensitivy issues with template parameter names which would require checking why they dont work. We had some users who used this couple years ago and now i just updated the code and copied it to gadgets to see if it would still work. However, there are our fiwiki files and configs as for an example if you want to try it out in frwiki.
--Zache (talk) 19:23, 30 November 2020 (UTC)
To load the gadget from enwiki (mw.loader.load( '//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-MediaWiki:RefToolbar.js&action=raw&ctype=text/javascript' );) it would require changes to enwikis version. This is how the most of the smaller wikis would like to do it so the upkeep would be centralized. --Zache (talk) 20:42, 30 November 2020 (UTC)