Interesting. It's doable, of course, but, I'm not sure that adding another button is the best UI. This should go through design and product to decide how to best approach it.

It's "doable" now: Open the citation as a reference (double-click), cut the template, paste it into the editor.

But… I'm not sure we should encourage this.

I agree another toolbar button is not the way to go.

One possibility is to create extra functionality for the template inserter instead- for instance, parse the json message, extract list of templates citoid theoretically supports, and then if a user selects one of those templates, offer a ref-free citoid template inserter. Or possibly extend it to add "citoid- inserted template" to the available list, or add a button somewhere inside the template selection dialog.

I would put something like that as fairly low priority though.

I would think that including this functionality IS important: its a low hanging fruit for experts and librarians to contribute to Wikipedia: part of the reason that we get resistance to expert contribution is the time factor, and the academic burden and professional burden that most experts place on their writing. If we told them: "we have a really simple tool that allows you to bring your research bibliography into Wikipedia for other researchers", I think we would get a lot more minor contributions from experts . Having an option to "add unreferenced citations" , also makes a lot of sense when big Wikipedias need more expert help and some projects, like German, don't require in-line citations, but focus on the relationship between sources and the text as a whole (more like traditional Humanist encyclopedias). The Wikipedia Library has had really good reception of https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Library/Cultural_Professionals from archivists and librarians, partially because we are telling them to do what they do best: create bibliographies.

In T95702#1198810, @Jdforrester-WMF wrote:

It's "doable" now: Open the citation as a reference (double-click), cut the template, paste it into the editor.

But… I'm not sure we should encourage this.

It is not quite obvious! Not everyone knows about double-clicked. I did not know about double-clicking until I read your post. When I open the page and there is a reference - I click on it and click on the button "edit".

Now double-click to the newly inserted link opens a form with fields. Form with the whole link text opens only for links that were in the article prior to editing.

I have also been unable to follow the instructions to get a citation out of the ref tags. I see the same windows as Sunpriat.

The only way I can do it now is to switch to source editing.

In T95702#2585921, @Mvolz wrote:

Does this double clicking on the reference and pasting the template outside help you?

It is very long. If I've inderstood what you mean, you have to

1. Open a draft page on VE
2. Generate the citation
3. Double click on the footnote call
4. Copy what you need

It is very long and complicated.
Plus it is not working for me and has been reported as a regression T134183: (regression) Enable every citation to be editable as basic citation: on step 4, template opens with all fields filled. Impossible to copy. :/

Ah, you're right, the double click thing doesn't work anymore :(.

The solution can be as simple as trying to detect if we are trying to put the citation just after a bullet. A bullet does not ever need a referencce after itself. As we only need this functionality for bulleted sections for bibliography, this seems to me as an optimal solution. - We can also give it as a help hint and that will be all needed.

+1 to @ManosHacker 's strategy on this: the only real use cases are in bulleted or in number lists.

I've tried to use bad faith to find counter-examples, but I failed. :)

I think that will work. Also, if you put a citation after a bullet, but decide that you want it in ref tags, then you should be able to copy and paste the citation template into a Basic Reference, which will convert it into a normal ref.

The more I work with VE and the new wikitext editor the more I get used to tools like citoid. For the time being, I switch from VE for creating a citation to wikitext for removing the ref tags in the Further Reading section.
I think the suggestion by @ManosHacker would be a good idea to start with.
I suggest to raise the priority of the task because it is really important to expert authors, as @Sadads has already pointed out.
I have opened a discussion on German Wikipedia.

In fact this has already been secretly implemented on July 2017 and it worked then (I checked Greek and English Wikipedias) but now is withdrawn.

In T95702#3805603, @ManosHacker wrote:

In fact this has already been secretly implemented on July 2017 and it worked then (I checked Greek and English Wikipedias) but now is withdrawn.

Why did this happen? Was there anything wrong with it?

Do you mean T169307?

Is there a reason "adding the citation without refs after a bullet" solution cannot be implemented nowdays?

Sorry about a "me, too" comment, but I'm just kind of excited about the circumstances: A few days ago I met a few people for a small "Art+Feminism"-style event, and showed them how to edit articles; it was the first time I did such a thing in over a year, because the COVID pandemic here is slowing down, and it was hugely refreshing.

Anyway, several of them wanted to add nicely formatted links in the style of "cite web", but to the body text and not to the footnotes. This is particularly relevant in Wikipedia articles about artists, which often have longish lists of links to exhibitions and online review articles. I had to tell them repeatedly to add the links as footnotes, and then remove the <ref> links manually in source mode. It's inconvenient, but still better than adding {{cite web}} templates and filling the fields by hand one by one.

So, there's still demand for it in 2021.

Why are we waiting to implement this easy solution to have inline citations after a bullet point? I can't motivate this missing functionality to participants of Wikipedia writing sessions...

In T95702#2586039, @Trizek-WMF wrote:

In T95702#2585921, @Mvolz wrote:

Does this double clicking on the reference and pasting the template outside help you?

It is very long. If I've inderstood what you mean, you have to

1. Open a draft page on VE
2. Generate the citation
3. Double click on the footnote call
4. Copy what you need

It is very long and complicated.
Plus it is not working for me and has been reported as a regression T134183: (regression) Enable every citation to be editable as basic citation: on step 4, template opens with all fields filled. Impossible to copy. :/

There's another workaround:

• Edit the reference
• Use "replace citation"
• Select the "manual" tab
• Select "basic" which opens the edit window for basic refs with the template inside (example screenshot)

• Now you're able to copy the content.
• As long as you don't add/delete content from the reference, it doesn't actually get converted to a basic reference, you can just close the the window.
• Paste the ref content somewhere in the article (e.g. in the further reading section)

Still very long, no? :)

Yes definitely very long (and not intuitive at all). Just wanted to mention it because the previously mentioned workaround doesn't seem to be working nowadays. But I just noticed that the workaround I described was already mentioned in T71498#4868396.

• perhaps, we should reuse code of copy citation from citer tool (https://citer.toolforge.org/). copied citation is prefixed with asterik ! video: https://commons.wikimedia.org/wiki/File:Citer-copy-citation-T95702.webm
• it becomes tricky when we try to introduce 2 buttons.
• default "publish" button is recognised by experienced users and it doesnt confuse new users
• is it feasible or without creating confusion, how can we add second button for mobile browser users also ?

• i left out important detail !
• copy citation button is under Shortened footnote and citation: on https://citer.toolforge.org/

Since my feature request has been moved to here (Thanks Johannes89 <3), I'll toss in my suggestion for an implementation. We already have MediaWiki:Cite-tool-definition.json to define custom Cite buttons, so simply add an opt-in boolean parameter to disable the automatic enclosure of <ref></ref> tags. This should cover all possible use cases elegantly, as it leverages an existing piece of tech and allows wiki administrators to use custom templates for whatever their use case is. It also keeps the interface clean for wikis that would not want to make use of this, as no custom buttons need be defined. The only potential downside is that, in conversations I've had, it seems like Cite-tool-definition.json is not particularly well known.

Example usage for a bulleted list reference:
MediaWiki:Cite-tool-definition.json

{
	{
		"name": "inline",
		"icon": "references",
		"template": "Cite",
		"title": "Inline Citation"
	},
	{
		"name": "bullet",
		"icon": "references",
		"template": "BulletCite",
		"title": "Bulleted Citation",
                "raw": true
	}
]

Template:BulletCite

* {{Cite|...}}

(Of course, assume Cite is defined as whatever the wiki's preferred template for standardizing citations is, and that BulletCite has the appropriate templatedata and passes the appropriate arguments to Cite's parameters)

Implementing could be as easy as to detect if there is a bullet (asterisk) as the first character in a new line just before a reference citation .
If the condition is met, the <ref></ref> are treated as ommited by the renderer.

Such an implementation would work in the very specific case of a bulleted list, but would result in multiple issues marked as duplicates of this one being re-opened as they require more general <ref> removal options.

I feel like we're just running in circles on implementation.

Personally, I have a strong preference for either a click box or a different user work flow other than auto-detect. I know this is slightly more work users but personally I don't like unpredictable behaviour if people don't understand why sometimes they get a ref tag and sometimes don't. A checkbox that remembers the last behaviour might minimise the amount of work but does clutter the UI. Could potentially also be a simple user script.

• default selection behaviour of checkbox: with checked or unchecked
• display checkbox at all: off/ on (for wikis that don't allow ref tags at all, i.e. now defunct wikinews but also this is the case for wiktionary and could make citoid useful for them. (Currently they asked for and use a config that hides the citation menu in the drop down instead of using it for citations.)
• for wikis that choose to display checkbox: remember last behaviour of user (if switching between aritcles with different behaviour)

So for en wiki something like:

{
defaultToRefTags: true
showRefTagCheckbox: true
}

For something like wikiquote that doesn't use ref tags:

{
defaultToRefTags: false
showRefTagCheckbox: false
}

Though maybe we only need one bool somewhere if we only have wikis that want it off entirely versus want it to be user checkable.
Not sure if this should be at the deploy level or via a message.

I'm fascinated by this thread (thank you for resurfacing this @Quiddity !) I agree with both:

• the workaround being too long (as @Johannes_Richter_WMDE pointed out in T95702#11496544), and
• that adding another button to VE can be confusing (as @Mvolz and @Jdforrester-WMF noted earlier).

I wonder if a third way – as @kalki seemed to suggest – could be the path forward. I see two separate (but compatible) options:

Option A: Extend citer.toolforge.org to accept multiple URLs and output a ready‑to‑copy bulleted list. Perhaps when you click "edit" on a bare URL like these, the tool could suggest using citer for bulk conversion?

Option B: Add a "Convert" button (like in the screenshot below) that works on one link at a time, either inside VE or as a standalone widget.

Any of these would:

• Keep the VE interface clean.
• Provide a dedicated bibliography workflow.
• Enable bulk processing (especially A) – a huge time‑saver.
• Be discoverable via a link or help page.

This seems practical and low‑UI‑impact, addressing both creation (T95702) and validation (T428554) without over complicating editors?

Also, as a potential idea, T428606 can be used.