Talk:WMDE Technical Wishes/Sub-referencing - Meta-Wiki

Hello @Johannes Richter (WMDE). I'm a bureaucrat on mk.wiki and I'm very grateful that we will finally have this feature. Until now referencing has been very silly without this possibility. I have a question: will there be a cross-wiki bot that will be replacing repetitive references (with only the page number being different, as we've done so far) with the new correct sub-referencing format? B. Jankuloski (talk) 12:07, 11 August 2024 (UTC)Reply

Hi @Bjankuloski06, thanks for your feedback! So far we have not considered such a bot for multiple reasons: Our work focuses on improving the MediaWiki software while bots are usually the prerogative of local/global communities. Additionally citation styles differ – not just among different projects, but also within a project (e.g. en:WP:Citing sources#Citation types...). Some users prefer templates, others don't use templates at all for referencing, some users might prefer to continue using workarounds like en:template:sfn for citing references multiple times with different details. While we hope that our solution get's widely used, we want to leave the decision to individual users – if you want to write a new article without using sub-referencing, there shouldn't be a bot enforcing the new syntax (especially if that bot isn't even community-owned).

We will try to help communities in other ways if they want to convert similar references to sub-references in existing articles. Part of our research was some analysis on how many similar references actually exist across all projects: We could probably use our data to provide lists of articles where sub-referencing can likely be used to local communities. Let us know, if you have other ideas (or other feedback on sub-referencing)! Johannes Richter (WMDE) (talk) 05:53, 12 August 2024 (UTC)Reply

Maybe you could offer individual communities that you convert the existing references by bot if they want it – this way, you don’t intervene in the wikis without being asked, but if communities want to adapt the new feature quickly yet lack the technical expertise to do so, you could help them out. —Tacsipacsi (talk) 20:15, 13 August 2024 (UTC)Reply

Hi @Tacsipacsi, thanks for the idea. We've discussed this in our team, but at this point we feel supporting a bot isn't something we could easily do. Choosing which details should be moved to a sub-reference heavily depends on the type of reference, citation style, citation templates etc. – therefore it seems best to leave this decision to humans. As some templates or tools working with citations probably need updating, it also seems like a good idea not to convert all references at once, but to start slowly, in case some unforeseen issues arise.

We can support communities by providing list of articles on all wikis in which there are "similar" refs, which we think are a good candidate for sub-referencing. And we can help by demonstrating how to adapt various templates like {{sfn}} to sub-referencing (given that templates – just like bots – are community-owned, that's another area where we don't want to interfere directly). Johannes Richter (WMDE) (talk) 09:52, 19 August 2024 (UTC)Reply

Came here to also ask about this. Maybe it could be added to an existing bot so maybe one could ask about it at the Bot talk pages as well as those of tools like reFill. This would be very useful on English Wikipedia where it could make the References section more compact and more overseeable.

A problem however is that because one couldn't specify the page / location in source until now, many people have not specified the page numbers etc and only cited the source once as a named ref without page number. For example, I usually did that instead of citing the same source twice or more times with different page numbers or appended notes. So like automated ways to merge references using sub-referencing I think there could (maybe should) also be some facilitation or support for specifying location in citation. For example, specifying page numbers where needed could become a requirement for good article status and/or there could be AI tools that read the statement and the source supporting it and suggest a page-number (e.g. as part of Suggested Edits that users only need to quickly confirm or deny).

Please comment here if there is a request for a bot or tool to merge references using this new Wikipedia functionality somewhere. Prototyperspective (talk) 17:49, 20 August 2024 (UTC)Reply

The problem you are mentioning with references without specified page number is just one of many ways references might be used in a way that makes auto-conversion via bot difficult / error prone. I could image some script similar to reFill which allows users to semi-automatically perform those conversions while keeping an eye on possible errors. We are currently thinking about how we can assist communities in adapting their citation tools and this might be one interesting use case. Johannes Richter (WMDE) (talk) 08:52, 22 August 2024 (UTC)Reply

1. To clarify, I didn't mean to say the bot should merge refs where the page number has not been provided, that's impossible if it doesn't also read the source. 2. Things that can be done automatically but are error-prone I think are best use-cases for Suggested Edits where people could check these edits and semi-automatic ways would be very useful as well, especially if added to already existing tools like reFill. 3. In any case, I think before that or bots are possible, it would need to work with inline named refs rather than only refs defined in specifically <references>. Prototyperspective (talk) 09:31, 22 August 2024 (UTC)Reply

Hi. You said that "Users across different projects are currently participating in moderated user testing." There are already problems on RTL wikis with every new feature, and there were such problems with references' new features. Is there an RTL wiki that testing the Sub-referencing right now? If not, can our hewiki be such a tester as usual for RTL? Again, as usual, I'm ready to present it to our community. IKhitron (talk) 15:31, 12 August 2024 (UTC)Reply

Thanks for reaching out @IKhitron! Our current user testing always involves users from both RTL and LTR wikis and we are aware of many existing problems with references in RTL wikis.

We'll reach out soon to some projects (RTL & LTR) about potentially becoming a pilot wiki for the new feature (it should be ready for pilot wikis by the end of September, if everything goes to plan). If your community is interested in becoming a pilot wiki, we would be happy to talk about it (although hewiki's predominant use of he:תבנית:הערה for creating references instead of using the <ref> syntax probably doesn't make it the best pilot wiki while the feature is still in development?) Johannes Richter (WMDE) (talk) 11:02, 13 August 2024 (UTC)Reply

Great. About the template, it's the only way in RTL when references can actually work and be useful, at least until their html code localisation some day in the future. So, from experience, it will do the double work, check usage of the new feature on the wrapped by templates references, and check proper work with templates too. And your always can pick two RTL wikis for the pilot, if you have your concerns. IKhitron (talk) 11:08, 13 August 2024 (UTC)Reply

Good point. There would need to be an update to the template once we deployed sub-references to hewiki (similar to the ref name and ref group parameters already available in the template). Johannes Richter (WMDE) (talk) 13:20, 13 August 2024 (UTC)Reply

Yes, I already started to plan them yesterday, and there is going to be a couple of updates on different wikipages in Template and Module spaces. Maybe even in Mediawiki space too, some CSS stuff. IKhitron (talk) 13:23, 13 August 2024 (UTC)Reply

Great, we would be happy to have hewiki as a pilot wiki then! What do you need from us to start discussing this with the hewiki community? Johannes Richter (WMDE) (talk) 13:39, 13 August 2024 (UTC)Reply

I'm glad to hear, thank you. Well, as far as I can see, if you turn this on in particular wiki, it wouldn't affect at all on any existing references, raw or template. So, there are two ways you can prefer. The first one is that I suggest to the community to try it on Village Pump, describe the new functionality, and send people to beta. A week later, if there is a majority, you can start. I believe it will be accepted with at least 80% of voices, but I can be wrong of course, if our tech users will suddenly find some problems. The second way is you turn it on before the discussion, I or maybe somebody others too will prepare all the template changes, and then suggest it to the community as a ready package. In this case, if suddenly the community will oppose, it should be turned down a week later. And also in this case, I'll need to talk to at least three people, to get their agreement to these changes, because I can't decide it by myself, of course. Well, it depends which way from these two you are going to choose. IKhitron (talk) 13:52, 13 August 2024 (UTC)Reply

Thanks, I'll discuss this with our team and reply later this week!

Personally I'd prefer the first option, although we should of course make it clear that currently testing on betawiki still shows some issues which will be fixed before deploying to pilot wikis. Given that we still need to do some work before deployment to pilot wikis can start, we would probably start discussions with the community in September. Johannes Richter (WMDE) (talk) 14:06, 13 August 2024 (UTC)Reply

Hi @IKhitron we've discussed your suggestions and would like to go with the first approach. We'll make a global announcement of the feature today, inviting people to test it on betawiki, hewiki will also get that message. We would be very happy if you could start a discussion about hewiki becoming a pilot wiki for this feature in 1-2 weeks, if that's fine with you? :) Johannes Richter (WMDE) (talk) 09:39, 19 August 2024 (UTC)Reply

Very well, @Johannes Richter (WMDE). In this case could you tell me, please, if there is a way of modeling a simple version of the hewiki template on Beta? I mean, is there a way of using rtl pages there? Can I create templates there? Because if I'll make something very simple, even without most of the features of the original hewiki template, it can help. IKhitron (talk) 09:59, 19 August 2024 (UTC)Reply

Hi @IKhitron, you can copy any templates and pages you need to en-betawiki to support testing. I just started with [1] which can be displayed correctly in Visual Editor and it's also possible to display the wikitext in right to left if you use the 2017 Wikitext editor [2].

We could theoretically deploy sub-referencing to Hebrew-betawiki, if it makes it easier to test your templates, but on he-betawiki it's not possible to test the Visual Editor solution, because the VisualEditor/Citation tool is only deployed to de- and en-betawiki. So if you want to test both wikitext and VE, we should stick to en-betawiki and create some he-pages + templates there. Johannes Richter (WMDE) (talk) 13:01, 19 August 2024 (UTC)Reply

Thank you. I'll try this. IKhitron (talk) 13:04, 19 August 2024 (UTC)Reply

Well, I tried, @Johannes Richter (WMDE). Two problems for now. 1) I can't create pages, because I need to be autoconfirmed. 2) It's quite impossible to work on ltr wiki, because it makes problems, such ax killing section editing, which should be a big part of community testing. RTL users almost do not use VE for references, because it has its own problems. So if you could indeed olen an rtl beta, it will be very appreciated. Not to say it will remain for the future wiki features. Thank you. IKhitron (talk) 13:17, 19 August 2024 (UTC)Reply

I could fix 1) by granting you confirmed permissions, but it seems better to deploy the feature on he-betawiki then. I've notified out team and will come back to you soon :) Johannes Richter (WMDE) (talk) 13:49, 19 August 2024 (UTC)Reply

Thank you. IKhitron (talk) 13:51, 19 August 2024 (UTC)Reply

Hi @IKhitron, I didn't know that it's already possible to use sub-referencing on any betawiki (except for the issue with the Visual Editor citation tool not being enabled on most betawikis).

So you can go ahead and create any hewiki templates on he-betawiki (if they aren't already present). Let me know if there's anything we can help with (e.g. adding you to the confirmed user group on he-beta). Johannes Richter (WMDE) (talk) 14:11, 19 August 2024 (UTC)Reply

┌───────────────────────────────────────────┘
Continuing to work, @Johannes Richter (WMDE). Is there a way to get an Interface Admin flag there? I need to edit freely mediawiki:common.js and mediawiki:common.css. What the procedure there? You can ask Amire80 for recomendation, if needed. For now I have Interface Admin on hewiki and ruwiki, by AutoIKhitron account.Thank you. IKhitron (talk) 14:40, 19 August 2024 (UTC)Reply

Done Johannes Richter (WMDE) (talk) 15:07, 19 August 2024 (UTC)Reply

Thanks a lot. IKhitron (talk) 17:59, 19 August 2024 (UTC)Reply

Well, I started here. There is a lot of work to do, but I already can see the first bug. The numbers in RTL are in opposite direction. Meaning, instead of 1.1, 1.2 and 1.3 for 1, we get 1.1, 2.1 and 3.1. IKhitron (talk) 20:49, 19 August 2024 (UTC)Reply

Thanks for testing! That's one of many RTL issues we are aware of. Our next development sprints will focus on RTL issues like that. Johannes Richter (WMDE) (talk) 16:51, 20 August 2024 (UTC)Reply

Great. And is there some deadline for this specific problem, before or after my pilot announcement to hewiki? IKhitron (talk) 17:05, 20 August 2024 (UTC)Reply

I'm honestly not sure. We want to tackle RTL issues like that before starting with pilot wikis, meaning at some point in September and probably before the community discussion about becoming a pilot wiki would start. I'll try to come back next week with more details. Johannes Richter (WMDE) (talk) 08:55, 22 August 2024 (UTC)Reply

Hi @IKhitron, I finally have an update. phab:T371232 summarizes most our current findings for RTL wikis: There are a couple of general, existing issues with citations on RTL wikis, which we want to look at later. We've fixed a couple of mobile RTL bugs for sub-referencing. For now the only major issue specific to sub-referencing we are aware of is the numbering issue you mentioned. We got feedback from other users sharing your opinion that the sub-reference number should be written 1.1, 1.2, 1.3 instead of 1.1, 2.1, 3.1. That's an issue we'll pick up soon.

Have you discovered other RTL bugs with sub-referencing? If so, we would love to get a list, so that our engineers can resolve them soon!

The hewiki pilot wiki discussion could start now from our perspective. We've shifted our plans a bit and would like to deploy to pilot wikis at the beginning of October, once we've updated visual editor workflows of sub-referencing. Nevertheless it's probably a good idea to start the hewiki discussion now, in case this leads to more users testing on beta und discovering unknown RTL sub-referencing bugs. We'll likely work with four pilot wikis, two of them RTL wikis, in order to be in close contact with the communities to implement feedback for further iterations and react fast in case any issues arise. Johannes Richter (WMDE) (talk) 15:36, 27 August 2024 (UTC)Reply

Thank you, I'll wait. And no, there are no more bugs for now.
About starting the discussion now, I'll do it if you insist, but I don't think it's a good idea at all. As it looks now for non-technical users and readers, the feature "doesn't work" in rtl, and the community may just decide not to use it at all, in tests or for real in the future. Is there a chance to have at least one of two major problems, nevermind each one, solved until, say, September 23? Because our wiki needs one week for such a decision, and you're talking about beginning of October. If one of the two will be solved, I could say them look, I informed about two problems, and one of them already fixed, so there is a hope. I'm talking about 3.1 and about the numeration styles. If there will not be each of them fixed until that date, the discussion will be much harder. You see, I have in mind not just testing, but also using it regularly after deployment. IKhitron (talk) 16:13, 27 August 2024 (UTC)Reply

Sounds like a good approach and I agree that presenting it right now might lead to people opposing it due to the unresolved issues. I'll report back to the team that these issues should be fixed before the hewiki discussion can start! Johannes Richter (WMDE) (talk) 17:01, 27 August 2024 (UTC)Reply

Once this becomes available, it will make |page= and |quote= somewhat tricky. It will then be best practice to include this information as a sub-reference, so that other sub-references can be attached to the origin cite, which remains clean of specific page # or quote data. The diffusion of information will create problems with tools, since being able to parse page numbers becomes tricky with information in multiple templates and locations. Plus, the option for sub-references to be named, makes it more complex. Plus, the possibility of other arguments being sub-referenced, such as authors in a multi-author book. It goes on. There is no way to control how users sub-reference (split off) information. I suspect this well-intentioned feature is going to cause a great deal of chaos. By splitting and diffusing information, it seems to be working against the semantic advantages of templated citations. -- GreenC (talk) 16:46, 16 August 2024 (UTC)Reply

I'm unfamiliar with how most tools interact with parameters like |page= and |quote=, but I think that most of the consequences – intended or not – will be beneficial. Of note, this extension should accomplish the laudable goal of finally obsoleting en:Template:Rp, which even the template creator wants.

Given that, I think it would be nice to be able to fine-tune the display of this extension. (This might be covered somewhere in the documentation already, but I didn't see it. Please let me know if I'm missing something obvious here.) Specifically, the default^[1.1] could be modified to display the page number or page span after a colon like {{Rp}}.^[1:181] Ideally this extension could read the value of the |page= parameter to make the display automatic, and the citation display style (enum.enum, enum:pages, enum∅lower-alpha, etc) could be controlled with behavioural switches at the page level. Folly Mox (talk) 18:00, 17 August 2024 (UTC)Reply

Breaking out pieces of data, currently contained in a single citation, spreading it out across the article in separate refs, is not good design. I understand the rationale, it is "good intentioned". Guarantee, people will be doing crazy things. Multiple authors? sub-ref. Multiple volumes? Sub-ref. Multiple editions of the same book? Sub-ref. Multiple identifiers? Sub-ref. etc.. good luck programmatically piecing a citation together, like Humpty Dumpty. The possibilities for sub-refs are infinite there is no way to predict how people will do it. Further complicated because the data in the sub-ref will often be free-form, not templated. It's a huge complication. All of our bots and tools will be adversely impacted. -- GreenC (talk) 04:42, 19 August 2024 (UTC)Reply

Hi @GreenC, thanks for your feedback! We are aware of the consequences you are naming.

• The issue with "diffusion of information" / "breaking out pieces of data currently contained in a single citation" doesn't seem different to the current approach with shortened footnotes?

If users don't want this, they can just stick to their preferred way of referencing. In dewiki (my volunteer home wiki) users are supposed to stick to the reference style of an article's main author and it seems like en:WP:CITEVAR basically says the same. Similar to the reason why people use sfn, our new feature might be very helpful for article's with lots of almost identical references.

• We've intentionally allowed sub-references to be used for any kind of details. This project was initially called "book-referencing", because page numbers are the most important use case for re-using references with different details. But there are many different kinds of details (e.g. citing a source multiple times, but with different quotes) which should also be supported.
• Yes, people will be able to use sub-references with lot's of different details. Multiple editions of the same book seems like a good use case. We'll display the details of sub-references after the main reference in ReferencePreviews, so it should work with any kind of details.

If communities don't want certain details to be moved to sub-references, they could rule out such usage (e.g. note in en:WP:CITE that multiple authors shouldn't be used for sub-references). Given that it's already possible to use references without any templates, it's not really new that people can come up with all kinds of (and probably some unwanted) variations of references, being able to write anything between <ref>...</ref>.

--Johannes Richter (WMDE) (talk) 09:34, 19 August 2024 (UTC)Reply

Shortened footnote templates have long been a problem for parsing, but limited in scope due to the complexity of their usage, so few people use them. They are edge cases, most tools and bots skip over processing them. This new system is relatively easy and standard, so will see a lot more usage, it won't be edge case, it will be mainstream.

We are trying to convert untemplated references to templated. This system is going to roll back a lot of that work, and create an even bigger problem because it's not only untemplated, but scattered across the article. -- GreenC (talk) 16:44, 19 August 2024 (UTC)Reply

What you could do, to address these concerns:

1. Limit which parameters can be sub-referenced. Right now there is clear consensus for page numbers and quotes.
2. Create a template for displaying those parameters in a uniform manner so it's semantic data.
3. If anything else is in the sub-ref, display a red error message and add to a tracking category.

In this way we can opt-in parameters, instead of trying to cleanup problems with complex and imprecise bots attempting to opt-out based on a guideline. -- GreenC (talk) 17:28, 19 August 2024 (UTC)Reply

We can't limit parameters for just one project, because we are building this feature for the global community. Your local community can of course create guidelines and mandate that only certain things like page numbers may be used with sub-referencing, if you can reach consensus for that. Similarly each community is free to create templates for sub-references themselves, templates have always been community-owned, that's nothing we can interfere with. And for similar reasons why 1) will not be possible we cannot do 3) as well, as the features needs to serve all communities, no matter if they want to use templates or not. From what I saw at en:WP:VPT#Coming soon: A new sub-referencing feature – try it! it also doesn't look like there is a consensus for limiting sub-references to templates – especially given that normal references can be used without templates as well and en:WP:CITEVAR explicitly allows (almost) all kinds of different referencing styles. Johannes Richter (WMDE) (talk) 09:02, 22 August 2024 (UTC)Reply

Maybe, just because the creator of {{Rp}} doesn't like {{Rp}}, that doesn't mean nobody else likes it. I think having hundreds of separate footnotes for page numbers can be distracting. Batrachoseps (talk) 02:40, 30 August 2024 (UTC)Reply

Hi. One more question. Is there a way to change the numeration style? Because it will be much better if the references will look on our wiki something alike 1a' and 1b', instead of 1.1 and 1.2. Or at least 1.a and 1.b, but it's worse. IKhitron (talk) 12:14, 19 August 2024 (UTC)Reply

I know this has been discussed in the past, let me ask the team about details and follow-up later. Johannes Richter (WMDE) (talk) 13:50, 19 August 2024 (UTC)Reply

I second this comment - would be very helpful. In general though, this is a good feature and a big improvement, so thanks for everyone's work on bringing it to life. Ganesha811 (talk) 14:42, 19 August 2024 (UTC)Reply

Hi, @Johannes Richter (WMDE), is there something new? Thank you. IKhitron (talk) 13:04, 27 August 2024 (UTC)Reply

Hi @IKhitron, thanks for the ping. Our team has talked about it briefly and agreed that this should be possible from a technical perspective, but due to vacations we cannot make a final decision yet / promise something specific. As I said below I'm quite sure there will be some way of customizing numeration, but right now I can't say this for certain. Johannes Richter (WMDE) (talk) 14:56, 27 August 2024 (UTC)Reply

I concur. This format is bad for those with low vision; the differnce between ^[1,2] and ^[1.2] is not very visible. Template:rp's format, ^[1]:2 or ^{[1]:Appendix B} etc., is better, especially as the part after the colon is a direct description of the location (for example, "2" is the pagenumber; saying "back cover" or giving the second in the video at which the statement starts are also permissible). This means you can look up the precise location directly, rather than via an indirect abstract reference, which also makes it easier to remember which cite is which. Letters might be good, but we need to avoid confusion with the letters used to link repeated cites from the reference-list section. HLHJ (talk) 11:32, 21 August 2024 (UTC)Reply

I think you andwered in a wrong section, the topic has nothing to do with all this. IKhitron (talk) 11:34, 21 August 2024 (UTC)Reply

+1 '1a', '1b' etc. style would be more readable for the visually impaired users and also more in line with citation styles in some non-English speaking countries. Wostr (talk) 12:27, 21 August 2024 (UTC)Reply

I see. Looks like you two somehow decided I'm trying to make the numeration shorter. I don't. I just want it to be standard in our wiki language, because the current one is weird there, and potentially could not be understood for some people. IKhitron (talk) 12:30, 21 August 2024 (UTC)Reply

Like I said: We're discussing if/how we can provide configuration options for local communities. If that's something we cannot do, we could at least support communities on how to make changes to their local CSS, which should also be a way of changing sub-reference numeration styles. Johannes Richter (WMDE) (talk) 07:14, 22 August 2024 (UTC)Reply

I think it would be great time to add a Duplicate feature to references in VE. Currently to duplicate a sub-reference you have to:

1. Open another browser tab with a 2nd article.
2. VE-Edit the 2nd article.
3. Go back to original, 1st article.
4. Copy from 1st to 2nd.
5. Copy back from 2nd to 1st.

It's not very hard with practice (if you know it is possible), but this could be much easier (and much, much more discoverable).

Added a feature request for ref duplication in the phabricator. Nux (talk) 15:07, 19 August 2024 (UTC)Reply

@Nux to make sure we're talking about the same problem: Your issue is that currently when using copy+paste in VE within one article, the copied reference automatically gets linked to the first one (-> ref name in Wikitext) and there is no way of un-attaching them in VE. Your workaround with a second article avoids this issue, but is of course very annoying, that's why you want a duplication feature. Our user tests have concluded that the copy+paste workflow is important to many VE users, so that's indeed something we've looked at.

We are still in the process of defining all the VE workflows for sub-referencing. If we make changes to the copy+paste workflow for sub-references, we might also be able to implement the requested duplication feature for normal references along the way (or at least make it easier to implement such a feature at a later point). But that's nothing we can promise. Johannes Richter (WMDE) (talk) 16:12, 19 August 2024 (UTC)Reply

Yes, you've understood correctly. Copying between different articles solves the problem for subrefs (and some problems with refs). Nux (talk) 19:37, 19 August 2024 (UTC)Reply

That's indeed an issue we've looked at during our research on re-using references, I've mentioned two similar tasks in your feature request -> phab:T372785#10084007. I'll discuss this with our team. Johannes Richter (WMDE) (talk) 09:18, 22 August 2024 (UTC)Reply

I realized that I forgot to follow up on this @Nux (just left a comment in phab:T372785#11673863): We've implemented a checkbox last November to allow VE users to decide whether they want to edit all instances of a re-used sub-reference or just a single one (phab:T406461 – and a similar feature for adding sub-reference details phab:T406454). VE users can duplicate sub-references and decide if they want to edit all re-uses of that sub-reference or only a single one. I've re-written your ticket accordingly. Johannes Richter (WMDE) (talk) 16:18, 4 March 2026 (UTC)Reply

About this new method, I'm a little disturbed that each sub-reference takes a whole line. It is possible to insert in the ref a parameter like columns in {{reflist}} which applies to the own sub-references ? A ntv (talk) 16:15, 19 August 2024 (UTC)Reply

Hi @A ntv, that's currently not possible, I will present your idea to our team! Johannes Richter (WMDE) (talk) 06:43, 22 August 2024 (UTC)Reply

Thanks a lot. A ntv (talk) 11:26, 22 August 2024 (UTC)Reply

Moving up a duplicative comment. I haven't tried subrefs yet, but I can see their use. I'd suggest adding template(s) like the harv set to format page ranges, quotes, chapter information, including authors, identifiers (doi, pmid, id), matching the relevant cite/citation family. If practical having multi-col subref page lists would keep the ref section succinct. See en:American Sign Language grammar for an example with Notes, References and Further Reading sections. The Notes section has a number of harvnb refs into References, I assume the harvnbs could be converted to sub refs in the Reference section, which is where the multi-col would help.

Unfortunately, as I understand it, the harv set of templates doesn't have one with parameters to provide full chapter information in a monograph or article information in a conference proceeding, hence the suggestion for a template above to be used with subrefs.

Example of attempt at chapter with harvnb, ... to avoid expansion, you need to block bots from adding more parameters for the book. US National Library of Medicine book chapters have a PMID & an ID like NBK[0-9]+,

{{cite web |first=C. |last=Darlington |title=The evolution of polymorphic systems |doi=10.1007/978-1-4757-0432-7_1 |url=https://link.springer.com/chapter/10.1007/978-1-4757-0432-7_1}} In {{harvnb|Creed|1971|pp=1–19}}

RDBrown (talk) 15:03, 21 August 2024 (UTC)Reply

Hi @RDBrown we're currently working without templates to allow all different kinds of different details in sub-referencing. I agree that templates can be very helpful, especially for providing formatting which the user then doesn't need to care about themselves. It will be up to local communities to decide if / which templates they want to use for sub-references, as templates are community-owned. I can discuss with our team how we could support with that. Johannes Richter (WMDE) (talk) 06:46, 22 August 2024 (UTC)Reply

The <references> tag is responsive, so depending on the number of references and the page width it will automatically switch to multiple columns. -- Ahecht (TALK
PAGE) 17:58, 11 March 2025 (UTC)Reply

I am coming to try this as a user of citation templates with the rp template to provide superscripted page references. While trying this new approach worked fine, the outcome on the page feels verbose, with a separate line for each extended ref. If one cites pages 10, 20, 25, 20, 28 of a journal article, there will be 3 added lines in the references section. By contrast, in-text rp refs ^1:10,^1:20, ^1:25,^1:20, ^1:28 seem tidier, as well as providing each checkable page number more rapidly to the reader. AllyD (talk) 10:35, 20 August 2024 (UTC)Reply

@AllyD I agree with you, however we also need to consider now there might be reuse of said sub-references so might look like ^{1:10^a b c d} ,^{1:20 a b c}, ^1:25,^1:20, ^1:28 Shushugah (talk) 22:48, 20 August 2024 (UTC)Reply

@AllyD thanks for testing our feature and leaving your feedback! You are right that solutions like rp allows for a simpler Wikitext when you are just working with page numbers. But Sub-referencing allows you to re-use references with all kinds of different details (example), where I would argue that having all those details in line next to the reference footnote might not be ideal. And template solutions like rp seem primarily designed for Wikitext, with a less optimized workflow in Visual Editor. But of course it's up to individual users to choose their preferred referencing style, most projects I think have similar policies to en:WP:CITEVAR. Johannes Richter (WMDE) (talk) 06:32, 22 August 2024 (UTC)Reply

The subreference is a great tool idea. But when I click on the "Extends" option in the visual editor, no visual options appear, only the text write the content of the extension appears. Will there be any visual options added to the editor in the "extends" tool to choose from? Elilopes (talk) 19:44, 20 August 2024 (UTC)Reply

@Elilopes You can begin type en:Template:Cite web and it will enable to add further content visually, but it's not super inviting/wonky interface to do so. But definitely should be feasible, UX consideration aside. Shushugah (talk) 10:23, 21 August 2024 (UTC)Reply

Indeed. We're currently going with a free form do allow sub-referencing being used with all kinds of different details. What you are used from normal references in the Visual Editor citation dialog relies on templates (like the one linked by Shushugah) which are owned by the communities. If our user testing – and the feedback from all of you currently testing sub-referencing on betawiki – shows, that a template-based dialog for sub-references (similar to the existing one for other sub-references) is desirable, we'll see if we can change this. Johannes Richter (WMDE) (talk) 06:15, 22 August 2024 (UTC)Reply

• Many if not most articles use {{reflist}} instead of <references>…</references> so this should also work with that. For example, people shouldn't be required to change the references syntax/template just for getting subreferencing to work and it usually wouldn't be used if that was required (e.g. when people only want to specify one extra subref).
• When named references are put into the references section they don't show up at places where sections or paragraphs have been transcluded (which is a very useful feature). It would be best if transclusions would automatically get all refs defined outside the transcluded section but at least for the near future they don't. Currently, when a ref is missing in a section transcluded to elsewhere one can usually fix this with the workaround of moving the named reference to the section that is being transcluded to other article(s) (which usually is only one section and hence doesn't cause problems in other transcluded sections).

While having bots and tools automatically merge refs for subreferencing as described above would be useful, I think fixing this issue described here is really essentially and also required before that can be done. Prototyperspective (talk) 13:52, 21 August 2024 (UTC)Reply

The reflist templates are difficult to integrate with, so we might not be able to have a simple way of automatically moving ref content around—however, there's still a way to manually write list-defined references without having to change from a templated reflist to an explicit <references> tag, by using the "refs" parameter to the reflist template.

Transclusing ref definitions and reusing or subreferencing refs from the transcluded content would be a fun idea, but there are some nasty problems to solve. For example, let's say your infobox template produces a ref with name="city-population" which you want to reuse outside of the infobox. There's no guarantee that the ref name will be stable, so a change inside of the template will have the surprising effect of breaking all pages relying on this tenuous connection. Note that it is already possible to reuse refs coming from inside of transcluded content, but it's almost never done and not supported in the visual editor, probably because of this coupling problem. Adamw (talk) 14:23, 21 August 2024 (UTC)Reply

• Yes I wondered if it would work with named refs within the reflist template – if it already works please add the info how to use this to the page and if not please make it possible. That doesn't solve the problem that it creates to much of a barrier to actually use named subreferencing – for example one has to edit the whole page in the wikitext editor instead of only a specific section.
• This could simply be solved by appending the article/page name or ID in front of the named ref included via transclusion.
• I'm not sure if you understood what I mostly meant with the problem of transcluded section, the thing you addressed was not the main point so here is another explanation: if in article A in section AA one uses uses a reference like so: <ref name="refname1"/> and defines that named ref in section AB and then transcludes section AA to article B that reference will not show up in article B and instead there will be the note Cite warning: <ref> tag with name refname1 cannot be previewed because it is defined outside the current section or not defined in this article at all.

Prototyperspective (talk) 14:44, 21 August 2024 (UTC)Reply

Reusing refs across transclusion boundaries is a separate feature, I would say. The current limitations are felt the most during visual editing, I know, and it's really unfortunate. The rendering of template-produced refs has incorrect numbering in the editor, and these refs don't appear in the reflist. We have some potential, minor improvements in mind but there are some conceptual obstacles: visual editor can't help edit template content, eg. list-defined refs passed through a {{reflist}} need to stay read-only, and coordinating the ref name eg. using "cid" currently lies outside of the Cite extension so is difficult to integrate with the editor's ref features. Improvements that I can imagine are achievable include making template-produced refs appear in the reflist, and fixing their numbering so it's interleaved with refs coming from the document being edited, as is done in read mode. Adamw (talk) 15:47, 23 August 2024 (UTC)Reply

Thanks for these elaborations albeit I may have not understand parts of it. I'm not sure if with "template-produced refs" you're referring to named refs defined withing {{reflist}} or refs using subreferencing (which template?) or something else. In the first case it wouldn't solve the problem of the references section needing to get edited when editing only a section (usually done with the source editor). The visual editor may not need to be able to edit it: there could be some new module that it uses that can in specific edit refs for subreferencing. If there are no reasons to use {{reflist}} instead of <references one could think about replacing all its uses via some bot and then deleting that template if that fixes these problems. That refs across transclusion boundaries is a separate issue doesn't mean the workaround of simply defining them in the section that is transcluded to elsewhere should be broken: I don't see why this wouldn't work with named refs defined not in the refs section but somewhere within the article. Prototyperspective (talk) 16:30, 26 August 2024 (UTC)Reply

I think there are good reasons to use {{reflist}}, which vary by wiki. Let's assume that this can't be changed unless the needs are satisfied by other means.

But the problem I'm talking about goes beyond just reflist. One example is that {{sfn}} creates a ref tag, and gives it a name calculated according to the authors and publication year. If these parameters are matched exactly in another {{sfn}} on the page, then the refs will be picked up as reuses. But if you want to reuse the ref from visual editor, you would have to exactly match the ref name and then the article would be dependent on a fragile, one-way relationship of an external page knowing how the sfn template does things internally, which is unsafe. When there were two sfn templates being called, the coordination between the template parameters and the resulting ref name was hidden from the page and could be freely changed in the sfn implementation. But once the name is hardcoded into an article, it becomes extremely difficult to find and fix all of these hidden reuses, in the event that the sfn template is updated.

This is just a demonstration of the challenge to the "transcluded section" use case that you describe. The author of that section would have to always worry that some other page might be transcluding its content, and would have to check these other pages before changing any ref names. Not an impossible task, but also not an ideal design.

Can you explain what you mean by the workaround being broken? Here I try to demonstrate what you've suggested, and it seems to work in reading mode: https://en.wikipedia.beta.wmflabs.org/wiki/CiteTransclusion Adamw (talk) 11:11, 29 August 2024 (UTC)Reply

That's why it would need to work with {{reflist}} then. I think getting this to work with inline named refs and then reflist is much more important than getting it to work with the Visual Editor. Most editors are not using VE and even if they would it would be relatively simple to briefly switch to the wikitext editor to create some subreferencing.

I may not have fully understood your example because I don't use sfn but that challenge is just more reason to make inline refs work – the person doing the transclusion does checks the section and editors reading a transcluded section and noticing a missing ref can fix it later if the problem arises later. This is not ideal so as said should be changed but that is a separate issue. The workaround of using inline named refs would get broken when having to move them to the bottom References section. Of course it works if you transclude the section into the same article. Transclusions nearly always are across articles. For example, here I transcluded the lead of the NRL article and had to move inline named refs to the lead to make them also show up there: European Green Deal#Nature Restoration Law. Prototyperspective (talk) 21:24, 29 August 2024 (UTC)Reply

For several years of editing, I have habitually used Template:Reflist (e.g. with Wikipedia:Kyoto Animation arson attack) because it seemed the most prevalent method on articles I cared about and was probably the recommended method when I first read Wikipedia:Citing_sources#Avoiding_clutter.

However, after taking an hour to review and reëxamine WP:FOOTNOTES, WP:LDR, WP:LDRHOW, Wikipedia:Citing sources, and Template:Reflist, I believe there are no functional differences between <references> … </references> and {{reflist|refs= … }}; I would be happy to change my habits to use the <references> method if it means being able to use the <ref extends="Miller"> functionality. Initially, I thought there might be possible deal-breakers regarding how group= or colwidth= fields are handled, but grouped references like <ref group=fn name=nytimes_20240921_foo> … </ref> seem to be handled similarly by <references group=fn> as well as by {{reflist|group=fn}}. As for {{reflist}}ʼs colwidth= parameter, I am happy with accepting the reference column defaults Wikipedia uses (via the Mediawiki Cite extension listed here), which seems to be 3 columns after 10 or more references are used.

The only parameter whose functionality I see missing from <references> is {{reflist}}ʼs liststyle= that facilitates alternate reference numbering systems such as with letters or roman numerals. If I have a suggestion, it would be to add the liststyle= functionality to the Cite extension so something like <references group=fn liststyle=lower-alpha> could replace {{reflist|liststyle=lower-alpha}}. Baltakatei (talk) 16:52, 21 September 2024 (UTC)Reply

Thank you for your investigations in this info! I haven't check if that really is the only notable difference between these two ways of ref sections and I also find that it seemed the most prevalent method on articles I cared about. However, this does this solve the points I made such as that having to edit that section will prevent people from making use of the extends feature and e.g. not be possible when just editing one section. Thus, a solution like a bot replacing all reflist templates with the corresponding <reflist> would be needed if this sub-referencing feature will not be made to work with the {{reflist}} which I think it really should. Prototyperspective (talk) 17:47, 21 September 2024 (UTC)Reply

Moving forward, it would be great to have a bit more information about Reference previews and tooltips. These are one of the "Problems for readers" of the current system, and are the main reason I use the rp template instead of the existing shorthand reference tools, so more detail on the solution found would be helpful in using the new tool. At the moment the preview shows the main reference and the subreference, which is great. It would be good to know how final and/or how customisable this display is. For example, must there be a gap between the 'two references' (main and sub), and must it be that wide? Best, CMD (talk) 06:19, 22 August 2024 (UTC)Reply

Thanks for posting your question here, @CMD. I have forwarded it to the team and will get back to you when we know more. I expect it might take a while as our current focus is on improving the Visual Editor part of the feature.

As Johannes said over here, updates around sub-references and Reference Previews will also find their way onto the project page WMDE Technical Wishes/Sub-referencing. -- Thanks for all your feedback and for taking the time to comment. Wishing you a good weekend, Johanna Strodt (WMDE) (talk) 11:34, 23 August 2024 (UTC)Reply

Pardon the illy defined heading, but that's because there are several issues that may expand into separate discussions if there is interest, so I'm just going to introduce them before I forget.

• List-defined refs – consider how this will work with List-defined references.
• Nested refs – how it will work with nested refs. One example is with Template:Refn. (Seems to me I saw somewhere a discussion about implementing Refn natively, but maybe I'm dreaming.)
• Interactions – how will subrefs work with various kinds of interactions. There are many, but just considering the two previous bullets, it is known that nested refs generally work in-line, and generally do not when they appear within list-defined references (see here, and task T22707 and task T26600 ). I hope you have test cases for various kinds of interactions, and at a minimum, anything you don't plan to handle now/cannot handle should be documented so there is no confusion among users of the feature.
• Citation wrappers – en-wiki makes extensive use of Citation wrappers (and so do some other wikis). They make it much easier to cite certain sources, but may trigger certain Module- or script-generated footnote warnings because (I believe) of the sequence of when templates are expanded vs. when the reflist is generated and what is visible to it at that time. Some band-aids have been created to mitigate the downside of citation wrappers (e.g., Template:Sfn whitelist) and they are effective, but one more thing (and a rather mysterious thing) for a user to have to attend to. Subrefs are an opportunity to handle Citation wrappers the right way.
• Know your audience –
  • who is the target (or market)? – who or what is this intended to help? Short footnotes (Template:Sfn, as implemented by Module:Footnotes) is well accepted, and already implements a portion of (what I view as) the main feature of your project, namely: ref consolidation. Sfn, like subrefs, allows a brief citation with minimal info to link to a full citation elsewhere, and consolidates similar ones in the reflist. The difference between the two is that sfn only consolidates citations with identical page values, whereas subrefs consolidate brief citations even if page values are different. (The less frequently used Template:Rp consolidates all of them regardless of pages; or to be more accurate, the native named reference feature consolidates them, however without duplicating the page numbers in the reflist.)
    Subref consolidation is a nice feature for citation geeks (Hallo!) but is that the main selling point? Most users never get past the lead of an article, let alone examine the arcane minutiae of reflist grouping. If that is the only benefit, I'm not sure how much money I would throw at it, just for a slight improvement in reflist elegance for the benefit of incorrigible wikinerds (like yours truly). Who else benefits?
  • expert feature – imho, this is an expert feature that will never attract wide usage. Many editors use minimal citation templates (if they use them at all). For example, I use Nardog's RefRenamer script to improve existing citations in articles, which gives me a window into a faux-random sample of actual citation template usage, and in the last one I did, a large majority of the citation templates lacked even an author field, and I find this to be typical (among articles with heavy use by VE editors). For the more intrepid users of citation templates, other methods already exist which do a subset of what you plan to do, and they attract little use, such as Template:Rp (used on < 1% of articles) and Template:Harvtxt/Citec (used on < 0.1 %). Early adopters and expert users will be the first (and perhaps only ones) to use the new feature, and at least with respect to the doc, you should set aside any concerns about it being confusing to its users.
• editing tools and platforms –
  • Visual Editor: VE users represent about 1/2 of new users' edits (per a comment by a WMF member; will have to find the commment again). What are the issues with using subrefs in VE?
  • Platforms: mobile users are over half of edits iirc; have you addressed possible issues with respect to use of subrefs with the mobile interface?

I know this is a grab-bag of stuff, please do feel free to break out responses in new sections (or subsections) if that will help; I fear that a single section for all of this might be a little chaotic. Thanks, Mathglot (talk) 20:37, 23 August 2024 (UTC)Reply

I just discovered this VPT discussion, and I think my post overlaps some of it. Mathglot (talk) 21:48, 23 August 2024 (UTC)Reply

Hi @Mathglot, thanks for your detailed feedback!

• List-defined references are exactly the approach sub-referencing is using, see WMDE Technical Wishes/Sub-referencing#Step by step. It's theoretically possible to define the main reference in the article text, but this would create a footnote marker for the main ref and usually only sub-references are supposed to have footnote markers in the article text.

• Some VE issues with list-defined references also affect sub-referencing, e.g. phab:T356471. We might be able to solve some of those general issues while working on VE sub-referencing workflows.
• We also have an unresolved issue with the reflist template some projects (like enwiki) use [3], editing in VisualEditor currently doesn't show the main reference, we'll work on that as well or help communities to update those templates for sub-referencing.

• Nested-referencing is one of the things we've discussed at VPT. I've provided one example of nested sub-references in that discussion. We are happy about more users testing things like that and providing feedback in case anything breaks.
• Interactions: Sub-references should usually behave like regular references -> existing issues will continue to exist with sub-referencing, but we are currently not aware of major new issues specific to sub-referencing and interactions
• Citation wrappers probably need an update to work with sub-referencing. We'll try to support communities (e.g. by providing documentation and examples) updating their citation templates. We recently had a Wikimania session on sub-referencing and citation templates (YouTube recording) and will continue to discuss this topic with the communities.
• Audience: We are fulfilling a long-term community wish. Some communities have adopted template based solutions like sfn for reusing references with different details, but others don't (dewiki being one of the largest projects without any existing solution). Most of the existing solutions work well for Wikitext users, but not for VE users. We are introducing a MediaWiki solution available for both Wikitext and VE. Our solution is a bit more complex in Wikitext compared to solutions like sfn or rp, but nevertheless we've had users currently working with both templates expressing interest in our solution. But we think we'll mostly benefit VE users by adding the option to re-use a reference with different details with a workflow similar to what they are already used to with normal re-uses.
• Editing tools and platforms: Sub-referencing is designed to work equally well in Wikitext / VE both on desktop and mobile. As I said we are still working on many VE workflows, that's why there are also some bugs to be fixed and features to be considered, e.g. phab:T369801 and phab:T372785. We are also still working on mobile issues, e.g. phab:T371666.

I hope that answers your questions? Johannes Richter (WMDE) (talk) 16:55, 27 August 2024 (UTC)Reply

I cannot reliably see the decimal point in two-part references on beta examples (and probably I'm not alone). It is rendered as either washed-out blue or very pale, very washed-out grey-blue (D2DBF3); the latter variant for me is almost invisible. I normally use same skin with a tad smaller font size and wide text area and never had issues with punctuation marks in references (but these were usually parts of alphabetic abbreviations so perhaps the brain reconstructed what the eyes did not see well). Retired electrician (talk) 19:42, 26 August 2024 (UTC)Reply

Hi @Retired electrician, thanks for your feedback! Sounds similar to what other users reported in #Numeration styles (changing the numeration style instead of the colour might me the solution...). We are currently discussing this and will respond soon. Johannes Richter (WMDE) (talk) 14:20, 27 August 2024 (UTC)Reply

On enwiki, CS1/2 templates create machine-readable data inside the reference. (I think it's called COinS.) Is it possible for subreferences to include these data, or only the ordinary references could include them? Janhrach (talk) 06:35, 28 August 2024 (UTC)Reply

Hi @Janhrach, while main references can use CS1/2 templates with machine-readable data (example), communities would need to make adjustments to their existing templates / create new ones for sub-references. I've seen someone [4] testing a demo template for sub-references they created on betawiki [5] and I'm sure it's possible to make such templates work with en:WP:COinS (and to basically "connect" them to a main reference template).

It's theoretically possible to use current citation templates in sub-references, but if you do that without adapting the templates, it shows an error [6], because the template expects parameters which are only used at the main reference. We'll try to assist communities adapting their commonly used citation templates and tools. Johannes Richter (WMDE) (talk) 12:07, 28 August 2024 (UTC)Reply

Thanks! Janhrach (talk) 18:47, 1 September 2024 (UTC)Reply

See Community Wishlist/Wishes/Make subreferencing work with inline refs and ((reflist)). I don't know much about how it could be implemented technically (what is needed for that) so this part of the proposal is a bit short. Prototyperspective (talk) 22:08, 21 October 2024 (UTC)Reply

Thanks, that's something we are currently investigating based on the feedback we've recieved already. See my full reply [7]. --Johannes Richter (WMDE) (talk) 07:51, 23 October 2024 (UTC)Reply

Hi, thanks to everyone who followed our work in the past months and years. We would like to ask for your perspective on changes to the original wikitext syntax of sub-referencing.

We based our original wikitext solution on list-defined references – a concept known and acceptable to most users according to our user research, although inline references are by far the much more common way of referencing.

Some users have asked to allow using sub-referencing within the article text instead of the reference section, because inline citations are more common, but also due to VisualEditor not being able to edit references in the references section if templates like {{reflist}} are used instead of <references />. The limitations of VisualEditor with regards to templates like {{reflist}} have been known for many years, but unfortunately we can’t solve them in our WMDE “re-using references” focus area. And thus, given how many wikis are using {{reflist}} or its local equivalent instead of <references />, list-defined references might degrade the experience in VisualEditor.

Given the issues with {{reflist}} and VisualEditor, the only option to move forward with sub-referencing is the following wikitext syntax:

Example text without sub-referencing:

According to scientists, the Sun is pretty big.<ref name="Miller">E. Miller, ''The Sun''. New York: Academic Press, 2005, p. 23</ref> In fact, it is very big. Take their word for it.<ref>E. Miller, ''The Sun''. New York: Academic Press, 2005, p. 48</ref> Don't look directly at the sun!<ref name="Miller" />

==References==
{{reflist}}

New sub-referencing syntax:

According to scientists, the Sun is pretty big.<ref name="Miller" details="p. 23">E. Miller, ''The Sun''. New York: Academic Press, 2005</ref> In fact, it is very big. Take their word for it.<ref name="Miller" details="p. 48" /> Don't look directly at the sun!<ref name="Miller" details="p. 23" />

==References==
{{reflist}}

Note: With this syntax, re-using sub-references looks a bit different to the way you are used to with re-using normal references. Normal re-use in the example above: <ref name="Miller" /> compared to a re-used sub-reference in the example above: <ref name="Miller" details="p. 23" />. You’ll need to copy everything from details="..." in order to create a re-use. The difference between re-using a reference and re-using a sub-reference becomes more visible if the sub-reference details are more complex, e.g. if a quote or template is used:

Advanced example text without sub-referencing:

According to scientists, the Sun is pretty big.<ref name="Miller">E. Miller, ''The Sun''. New York: Academic Press, 2005, chapter 1, page 23: "The Sun is also quite hot, while the moon is very cold".</ref><ref>R. Smith, "Size of the Moon", ''Scientific American'', 46 (April 1978): 44–46.</ref> In fact, it is very big.<ref>E. Miller, ''The Sun''. New York: Academic Press, 2005, chapter 2, page 40.</ref> Take their word for it.<ref>E. Miller, ''The Sun''. New York: Academic Press, 2005, chapter 2, page 48: "The moon is not so big".</ref><ref>Drake, A. (2023). "The Solar Phenomenon: A New Era of Sun Research", ''Solar Science Press''.</ref> Don't look directly at the sun!<ref name="Miller" />

==References==
{{reflist}}

Advanced example with new sub-referencing syntax:

According to scientists, the Sun is pretty big.<ref name="Miller" details="{{cite book details |chapter=1 |page=23 |quote=The Sun is also quite hot, while the moon is very cold}}">E. Miller, ''The Sun''. New York: Academic Press, 2005</ref><ref>R. Smith, "Size of the Moon", ''Scientific American'', 46 (April 1978): 44–46.</ref> In fact, it is very big.<ref name="Miller" details="{{cite book details |chapter=2 |page=40}}" /> Take their word for it.<ref name="Miller" details="{{cite book details |chapter=2 |page=48 |quote=The moon is not so big}}" /><ref>Drake, A. (2023). "The Solar Phenomenon: A New Era of Sun Research", ''Solar Science Press''.</ref> Don't look directly at the sun!<ref name="Miller" details="{{cite book details |chapter=1 |page=23 |quote=The Sun is also quite hot, while the moon is very cold}}" />

==References==
{{reflist}}

In the advanced example, you can see that it is also possible to use templates in the details attribute. There won’t be a noticeable difference between re-using a reference and re-using a sub-reference in VisualEditor.

Please note: If you wish to use quotation marks " within details="..." (e.g. when inserting a quote), make sure to use " instead. Alternatively, editors can use templates which return a quotation mark in the reader view, like in the template example above. VisualEditor users will be able to type " when filling out sub-reference details, it will be converted automatically to " in wikitext. Other special characters which might need to be handled similarly when used with details="..." are < and >.

• Can you see yourself using this wikitext syntax?
• Does the new sub-referencing syntax fulfill your needs? Are there any needs which are not met?
• What are your thoughts on the way re-using inline sub-references works, and on the special character limitations?
• Please indicate if you think this approach is worth moving forward and why (or why not)

Thanks for your feedback, it’s highly appreciated! --Johannes Richter (WMDE) (talk) 13:05, 17 December 2024 (UTC)Reply

1. Yes, I would definitely use it. It's well organized.

2. It currently meets my needs.

3. Details is the key word in subreferencing. This limitation does not prevent its use.

4. Yes, keep going. It's nice and tidy. Elilopes (talk) 16:16, 17 December 2024 (UTC)Reply

Thanks for your feedback! Johannes Richter (WMDE) (talk) 17:20, 17 December 2024 (UTC)Reply

Thanks to the entire team for the update and your continued work on this! I'm not sure I prefer these changes to the syntax over the prior one which used the extends attribute. I appreciate the want to move away from a system that forces users to write list-defined citations, but I don't believe the losses in reusability and simplicity outweigh the benefits. One of the primary reasons sub-referencing has been an exciting prospect has been the elimination of duplicate information in citations, and the need to copy the contents of the details attribute with this syntax stands against this idea. Escaping special characters is another layer of complexity that is bound to cause confusion, especially as this behavior would be inconsistent with the normal way of defining references (i.e. without sub-referencing) where escaping is not required. —TechnoSquirrel69 (sigh) 17:08, 17 December 2024 (UTC)Reply

Thanks for your feedback @TechnoSquirrel69! Regarding "elimination of duplicate information in citations": This goal is still achieved in the reader's view with the more organized reference list. But you are right that the wikitext probably doesn't get reduced with the details sub-referencing syntax (as soon as the details are more complex than just a page number, which is fortunately the main use case).

How important is a reduced wikitext to you? Do you feel this is of similar importance to you / other editors than the improved the reader's view? Thanks for your thoughts on copying sub-references and special characters, that's indeed a limitation of this new syntax. Johannes Richter (WMDE) (talk) 17:42, 17 December 2024 (UTC)Reply

Ah, I see you're right that the duplication would not occur on the readers' side. That makes it better, but the wikitext duplication still compounds upon the other issues I mentioned with the details attribute. I feel like these would add up overall to a confusing and inconsistent experience for editors. Again, I understand that you want to be able to support inline citations, but I hope that another method can be chosen that doesn't come with as many caveats.

If you could entertain me for a moment, I had an idea for a possible solution that works using the old syntax. Keep in mind that I'm not a programmer nor am I particularly familiar with the Cite extension, so take this with the appropriate grain of salt. I assume the old syntax required using a list-defined reference when creating the full citation to avoid a visible footnote being added in the text. (Please correct me if I'm wrong!) However, it could still be defined inline if an attribute, say, "baseref", exists to hide the footnote.

<ref name="Miller" baseref>E. Miller, ''The Sun''. New York: Academic Press, 2005.</ref><ref extends="Miller">Page 23.</ref>

== References==

{{reflist}} (or <references/>)

This setup with the full citation followed immediately by the details is already in use for templates similar to {{rp}}, so I don't see it as a massive workflow change. I see this as an improvement over the new syntax since it should introduce no other complications and support all the things I like about the old syntax, including being able to name and reuse sub-references. Thoughts? —TechnoSquirrel69 (sigh) 18:34, 17 December 2024 (UTC)Reply

You are right, we used list-defined references in the previous extends solution to avoid issues with showing a visible footnote in the article text for the main reference. We have considered using an attribute to hide the main reference's footnote, but from what we've learned in our user research there is a lot of potential for confusion – currently every ref-tag creates a footnote marker. Especially for communities using templates which create (sub-)references (we know that's the case in some right-to-left language versions) this might lead to a bad user experience. Similarly if a sub-reference is used within templates like infoboxes, using such a hide attribute might make it difficult to locate it in VisualEditor, which is already bad to deal with references within infoboxes. Johannes Richter (WMDE) (talk) 11:43, 20 December 2024 (UTC)Reply

Thanks for introducing the idea of using boolean attributes like baseref, IMHO the syntax looks nice. I've quoted your example with a slight change at another discussion on WMDE. T. Wirbitzki (talk) 08:44, 26 January 2025 (UTC)Reply

Hi. I'm not sure I understand what happened. Did you change the new syntax such that there was a way for sub-references naming before, but it is removed now? Why? Looks like a regression to me. Thank you. IKhitron (talk) 18:36, 17 December 2024 (UTC)Reply

Hi @IKhitron, sorry for the late reply. The previous approach relied on list-defined references which would cause limitations for VisualEditor users. By using in-line referencing instead we are making sure that sub-referencing works equally well for both wikitext and VE users which is a requirement for sub-referencing to happen. This comes at the cost of the option to assign names to sub-references. We believe it should be fine to re-use a sub-reference by just copying it in wikitext – especially in simple cases like <ref name="Miller" details="page 40" /> – although we understand that assigning a name might have been the preferred option if there were no other limitations to consider. Johannes Richter (WMDE) (talk) 20:04, 8 January 2025 (UTC)Reply

@Johannes Richter (WMDE) Is the extension converting "p. 23" to "Page 23.", or is that a mistake in the screenshots? -- Ahecht (TALK
PAGE) 22:33, 17 December 2024 (UTC)Reply

oh, thanks for noticing @Ahecht, that's a mistake in the screenshots. Johannes Richter (WMDE) (talk) 07:57, 18 December 2024 (UTC)Reply

That seems great. I love that it's just simple to start with and have the option to use some templates in the new attribute. Personally I see myself using that without templates most of the time.

Special characters should be fine, I expect most users just use [a-z. 0-9:] to specify pages or time (for videos etc). On plwiki if someone would want to use quote they would probably use pl quotes „”.

Minor problem is that we (plwiki) currently check if book citation template contains pages specification. Not a big deal I think, I guess we can just remove that validation. I did expect this would happen (that things would be detached and not possible to validate as a whole). In some future maybe ref would not use templates, just attributes... But I think that's not for now.

So now I'm just curious what will gui/ui/ux look like 🙂 Nux (talk) 23:24, 17 December 2024 (UTC)Reply

Thanks for your feedback! We also assume that sub-references will mostly contain [a-z. 0-9:] (because book pages are by far the most common use case) – pl quotes „” are not a problem.

Yes we assume that some templates need to be updated for sub-referencing. We'll notify communities in advance and try to assist (e.g. by providing examples on how to update reference templates) if we move forward with this proposed sub-referencing solution. We'll reach out to communities once sub-referencing with the new syntax can be tested in VisualEditor. Johannes Richter (WMDE) (talk) 15:03, 27 December 2024 (UTC)Reply

I do not like this new syntax. Putting wikitext inside of an XML-style attribute seems like it will be a huge mess waiting to happen. Anomie (talk) 23:57, 17 December 2024 (UTC)Reply

Yeah, +1. Not a fan of <ref name="Miller" details="{{cite book details |chapter=1 |page=23 |quote=The Sun is also quite hot, while the moon is very cold}}">E. Miller, ''The Sun''. New York: Academic Press, 2005</ref><ref>R. Smith, "Size of the Moon", ''Scientific American'', 46 (April 1978): 44–46.</ref> […] <ref name="Miller" details="{{cite book details |chapter=2 |page=40}}" /> one bit. It also breaks all existing expectations for bots, since they are usually supposed to ignore HTML tags but in this case, if someone wanted to replace a template, they would need to touch them. There are already too many problems with templates inside refs (for example, you still after 20 years of MediaWiki can’t substitute anything inside a ref), we shouldn’t be multiplying them. stjn^[ru] 21:51, 19 December 2024 (UTC)Reply

Thanks for your feedback. Yes wikitext inside the reference attribute is a bit unusual, but from our perspective the best compromise to deal with various limitations and make sub-referencing possible for both wikitext and VisualEditor.

I personally agree that using complex templates within sub-references has some disadvantages, we nevertheless wanted to demonstrate this more complex use case, in case communities are considering this. I believe the most common use case will be something as simple as <ref name="Miller" details="page 40" /> which should be fine, even if it's unusual to place this within the attribute? Johannes Richter (WMDE) (talk) 15:18, 27 December 2024 (UTC)Reply

Potential technical problems of using ref name="Miller" syntax:

• As far as I know you can't set the name of the refs in the Visual Editor - although you can set the group name, so it probably also could be added (unless there's already a technical problem with it, and that's why it wasn't added along with the group).
• Templates used inside a ref tags can't use a "subst".

MarMi wiki (talk) 01:46, 18 December 2024 (UTC)Reply

Thanks for your feedback. Yes VisualEditor currently assigns automatic ref names (something like :0) which isn't very useful for wikitext users. There are several open Phabricator tickets related to this issue (e.g. phab:T92432, phab:T334073, phab:T245199). We are considering to add a prompt for VE users to enter a meaningful name instead of the autogenerated one, which would be beneficial for both sub-referencing as well as re-used references. But we currently can't promise anything because we still need to do new user tests with in-line sub-referencing in VisualEditor if the syntax receives positive feedback.

Regarding templates: I personally don't believe that templates will be used a lot with sub-references. The most common use case will likely be something simple like <ref name="Miller" details="page 40" />. And if communities decide to use templates within sub-references, I don't believe that's much different to current citation templates which cannot be substituted as well? Johannes Richter (WMDE) (talk) 15:37, 27 December 2024 (UTC)Reply

The previous syntax was far better and more intuitive. I hate putting complex wikitext with transclusions inside a tag attribute, and it's confusing a ref tag with details can be not self-closing and thus content that appears first in the output can be given second in the source. Why not make details a boolean attribute, or a tag on its own to be put inside ‎<ref>...‎</ref>? Nardog (talk) 10:35, 18 December 2024 (UTC)Reply

Thanks for your feedback! Based on the user feedback we received so far, sub-referencing should be usable with many different details, that's why a boolean attribute would be too restrictive. We didn't want to put a tag on it's own inside <ref>...</ref> to keep it closer to the existing syntax for references (ref name, ref group...).

I understand the concern about complex wikitext inside the details tag, although that's just an example how a more complex use case would look like. We assume the most common use case (by far) will be <ref name="Miller" details="page 40" /> which doesn't seem too complex? Johannes Richter (WMDE) (talk) 14:26, 31 December 2024 (UTC)Reply

@Johannes Richter (WMDE): I don't understand what sub-referencing should be usable with many different details, that's why a boolean attribute would be too restrictive means. What's wrong with <ref name="Miller" details>page 40</ref>? Nardog (talk) 16:22, 4 February 2025 (UTC)Reply

I definitely could use this, but I think it would be far better if we could reuse them. Could we implement something so that the subreference is generated with <ref name="moon big" extends="Miller" details="p. 23"/> (“Miller” being the existing ref) after which <ref name="moon big"/> would reuse the same ref? Aaron Liu (talk) 13:24, 18 December 2024 (UTC)Reply

Sorry, looks like this was the original proposal. I think there are existing limitations with VE, and another one not-too-impactful like this wouldn't hurt. Aaron Liu (talk) 01:40, 20 December 2024 (UTC)Reply

Actually, we could keep the details= tag and have the content of "Miller" put within the ref tag if VE can't find the references tag. Aaron Liu (talk) 01:41, 20 December 2024 (UTC)Reply

Thanks for your feedback! That's indeed one major difference to our original proposal, which basically allowed to assign a new name to sub-references in order to allow for cleaner wikitext. Introducing two new attributes (extends + details) instead of just one (details) could make the syntax too complicated for less technical / inexperienced users.

Regarding VE limitations: You are right, that many of them already exist, however we agree with the WMF editing team that we shouldn't add new ones – especially not if we hope that the feature will be widely used by communities. Johannes Richter (WMDE) (talk) 14:37, 31 December 2024 (UTC)Reply

I believe it's more confusing if two invocations of name="Miller" result in two different citations. It's much more widely established that using name="Miller" reuses a reference, and changing the old instead of only extending the new results in more confusion over apparently inconsistent behavior. Aaron Liu (talk) 14:57, 31 December 2024 (UTC)Reply

@Aaron Liu I think it's still working similar to the way people are used to? name="Miller" re-uses the content from the main reference (the same across all re-uses). What's new is that details="..." changes which details are displayed next to the reference's main information. That doesn't change anything about re-using all the content from the initial name="Miller" main reference, just like with re-using regular references? Johannes Richter (WMDE) (talk) 20:10, 8 January 2025 (UTC)Reply

It generates a new reference sub-entry. That looks like a new reference to me, just with an additional parental relation. Aaron Liu (talk) 22:52, 8 January 2025 (UTC)Reply

When precisely do two subreferences merge? Will <ref name="Miller" details="p. 23"/> and <ref name="Miller" details="{{a template which yields p. 23}}"/> be a single subreference? Thank you very much! 慈居 (talk) 17:59, 28 December 2024 (UTC)Reply

If the content is identical, it's merged automatically. Once you change something (even if it's just a template which yields the same content) it will show two separate sub-references. That's similar to the existing ref name behavior, where two identical references are merged [8] and small changes lead to an error [9]. Johannes Richter (WMDE) (talk) 12:00, 31 December 2024 (UTC)Reply

Thanks for the information and also all your contribution. I like the idea of subreferencing very much. Still, I personally prefer the original syntax, since when editing re-used identical details I only have to edit once. And I somehow have psychological fear of having a wikitext-valued attribute. ;) 慈居 (talk) 21:22, 8 January 2025 (UTC)Reply

Firstly thanks for all your hard work and consultation. As long as it works on Visual Editor I don’t care what the syntax is. As this was first requested over a decade ago and so many people want it what are the chances of it going live in 25? Chidgk1 (talk) 08:11, 29 December 2024 (UTC)Reply

We'll carefully evaluate the results of this consultation in the next weeks. If there's a way forward with the syntax presented here, we want to finish our work and go live with sub-referencing in 2025. Johannes Richter (WMDE) (talk) 12:15, 31 December 2024 (UTC)Reply

Many good propositions, though a bit like a fireworks (it's season :-)) : sparks go in too many directions to be able to follow a good one. I think i have seen everything i would need and more, but some possibilities confuse me.

First, the scope of this proposition : I won't go to the resulting formats, since everybody seems to agree (= I haven't seen any disagreement). I also won't discuss the specificities of VE which I barely use = I am not competent. I'll only invoke the wikicode syntax extensions part.

For me, I'ld like to stick to some sort of principles, which could be the following :

• all the content text for the references and sub-references are bracketed by <ref>...</ref>, and moreover, outside the tags ;
• inside a <ref ...>, options are either a kind of "status", such as «baseref» or «details», or meta-references, such as : « name="maintadaa" » for any re-use, « extends="maintadaa" » for sub-referencing. The tag closure « ... /> » says that there is no stuff in between the tag pair <ref...> </ref>.

Examples of use which I hope to be the most extensive (plese, do complete this list if I miss some uses) :

• <ref>A simple reference, neither sub-ref'ed nor re-usable.</ref>
• <ref name="Reusable1">A re-usable reference.</ref> (Should it be sub-referenceable ? The least surprise principle says it should, but this may not be simple to program…)
• <ref name="Reusable1" /> === its simple re-use.
• <ref name="Reusable2" baseref>A re-usable reference, potentialy to be sub-ref'ed.</ref>
• <ref name="Reusable2" /> === its re-use without subreferencing it.
• <ref name="Reusable2" details>A sub-reference part, not re-usable.</ref>
• <ref name="Reusable2" details="Reusable3">A sub-reference part, re-usable.</ref>
• <ref name="Reusable2" details="Reusable4">Another sub-reference part, also re-usable.</ref>
• <ref details="Reusable3" /> === its re-use as a sub-ref'.

  + these six last citations require somewhere a « <ref name="Reusable2">...</ref> », or equivalently a « <ref baseref="Reusable2">...</ref> »...

• <ref baseref="Subreferenceable">...<ref> : synonym to <ref name="Subreferenceable" baseref>...<ref>. In fact, presently, I see no needs to differentiate the role of « name="..." » from « baseref="..." », apart for the wikicode reader, since «baseref» semantically explicites future sub-referenciations. Why not keeping both of them as synonyms ? Same thing for «details» and «extends», I think : synonyms in function and in results, though semantically slightly different ; therefore, at least in a first version, no needs to differentiate their treatments. -- @Éric38fr^{('tchatting, a good drink in hand)}, 22:13, 2 January 2025 (UTC).Reply

  That's a lot more complicated than what I proposed. Aaron Liu (talk) 02:33, 3 January 2025 (UTC)Reply

  Thanks for your suggestions @Eric.LEWIN! We tried to keep our approach as closely to the existing citation system as possible, in order to make sure it's not too complicated. Introducing more than one new attribute (in your examples baseref + details) seems to have a high potential for confusion? Johannes Richter (WMDE) (talk) 20:15, 8 January 2025 (UTC)Reply

I think that the syntax that exists now on testwikis is great, and there is no need to change it, especially when absolutely everyone in this discussion do not support the new proposition. IKhitron (talk) 18:45, 5 January 2025 (UTC)Reply

Thanks for your feedback! As I explained above we need to make sure that sub-referencing works equally well for wikitext and VisualEditor users. The previous approach had several unsolved limitations for VisualEditor and we are not in a position to fix them, which is why we needed to change our syntax. Now we are evaluating if (or under which circumstances) users believe it's worth moving forward with this approach. Johannes Richter (WMDE) (talk) 20:25, 8 January 2025 (UTC)Reply

Well, I don't think that solving a big problem with creating a huge problem is a good idea. IKhitron (talk) 21:17, 8 January 2025 (UTC)Reply

The syntax provided here seems a bit restrictive in terms of narrative footnotes – something like Gruen 1995, p. 123, however notes that Dio, 3.14.15, contradicts the narrative in Suetonius, Julius, 1.2.3 or But see Woodman 2021 for alternative views on blah blah. I use narrative footnotes heavily both on Wikipedia and in actual work. In general I am of the view that a footnote should explain how the source supports the cited statement. I'm also not a huge fan of the anchors; imo anchors should closely match display text. (These remarks are edits to remarks initially on the English Wikipedia, from where this discussion was linked.) Ifly6 (talk) 20:19, 1 April 2025 (UTC)Reply

Is there any reason to not support explanatory footnotes? -- Chatul (talk) 13:54, 9 April 2025 (UTC)Reply

We would also like to take the opportunity to learn more about your main reasons for using {{reflist}} (or its local equivalent) despite its known limitations for VisualEditor, in case this becomes relevant for future work on references. As far as we know, the template was introduced, because <references /> was missing important features like multi-column view (which was added a couple of years ago).

• What other {{reflist}} features are important to you?
• How should <references /> be improved?
• Under which circumstances would you consider moving away from the {{reflist}} template to avoid VisualEditor limitations (similar to other projects like itwiki)?

Thanks for your thoughts! --Johannes Richter (WMDE) (talk) 13:05, 17 December 2024 (UTC)Reply

This is mostly just inertia. At plwiki we was able to almost completely move away from defining refs in a template. There is a script that cleanup code and changes the template to tags. So we did use that kind of template, but after some debates (hard debates) we were able to move on.

As a compromise we now use a template but without refs inside. The template has a Polish name and some people still refuse to use VE, so names in code are kind of still important. Hopefully with better tools this will fade away. Nux (talk) 23:44, 17 December 2024 (UTC)Reply

To be clear:

• instead of <references /> we are still using {{Przypisy}} (its not harmful for VE flows)
• we semi-automatically replace {{Przypisy|<ref>...}} with <references> <ref>... (at the moment we didn't decide to replace everything, so we are in the process of migration)

Nux (talk) 23:22, 18 December 2024 (UTC)Reply

I'm thoroughly of the opinion that on enwiki we should be defaulting to ‎<references /> instead of {{reflist}} everywhere except for cases where we're using the syntax defined at en:Template:Reflist/doc#Predefined_groups to change the numbering to letters or roman numerals, if for no other reason than that it still works even when we've exceeded the post-expand include size limit. Even in those cases, other templates such as {{notelist}} exist. However, the times when I've tried to spread the gospel of ‎<references />, such as at en:Help:Introduction to referencing with Wiki Markup/2, I've gotten pushback because {{reflist}} is seen as "friendlier" than HTML-like tags (in that case, the specific reason was it's more important to teach them wikitext than to teach them HTML). -- Ahecht (TALK
PAGE) 01:03, 18 December 2024 (UTC)Reply

I can easily change from “reflist” to references” as for the articles where I need subreferencing it is just used for multi-column view and I doubt many people care about that. But I just created a user on beta(have never tried beta before) and when I create a draft article it defaults to “reflist”. If I was new to Wikipedia I would be unlikely to change that. So I suppose to test realistically I need to wait until the draft default works with subreferencing? Is that draft default going to remain as “reflist”? Chidgk1 (talk) 08:14, 29 December 2024 (UTC)Reply

Last month we asked for feedback on a new approach to sub-referencing. Thanks for your responses, some of you have provided input on this project for many years which is highly appreciated! We are creating sub-referencing for and with the community, making your feedback so valuable and always at the core of our considerations. That’s why we were faced with the question whether to proceed with the new syntax proposal or to stop our work on sub-referencing.

We’ve presented the new syntax in response to multiple limitations we encountered while working on the VisualEditor implementation of sub-referencing (e.g. issues with list-defined references in combination with templates like {{reflist}}). 30 users from 12 different projects responded to our call for feedback with mixed reactions, although overall more positive responses. After careful consideration of the feedback we gathered in the call for feedback and in user testing sessions we’ve decided to move forward with sub-referencing based on the new "details"-syntax:

All comments have in common that there is a clear need for sub-referencing to solve some of the inherent problems you are facing with re-using references, and users have been waiting for it for years. Sub-referencing will greatly improve the readability and clarity of reference lists, by neatly grouping references with different details. This makes it easier for readers to understand how often a source has been used and judge an article’s reliability or verify a claim.

As an editor using VisualEditor, when re-using a reference with different details, you’ll avoid the laborious effort of re-creating it from scratch, or accidentally overriding an existing reference. Similarly wikitext users equally benefit from no longer having to repeat an entire reference when using a source multiple times with different details, which is more error prone than just creating a sub-reference. This will also allow for a more organized wikitext.

Additionally sub-referencing no longer requires template-based workarounds like {{sfn}} which usually don’t work properly in VisualEditor.

Some users preferred the previous "extends"-syntax or presented alternative ideas of how the sub-referencing syntax should look like. Most of them would have similar limitations as the old "extends"-syntax or create technically complex code which will be too hard to maintain in the future according to the joint assessment of both our team (WMDE Technical Wishes) and the WMF editing team. Therefore alternative approaches could not be considered.

Others pointed out that wikitext inside an XML-style attribute (details="...") is unusual, especially if templates are used. We believe that there is precedent for such attributes, e.g. the caption="..." attribute in galleries or the text="..." attribute in Kartographer. We see the concerns about templates. Therefore, we will initially not allow the usage of templates in the details-attribute of the new sub-referencing syntax and evaluate the potential benefits and downsides of using templates while testing with pilot wikis.

The other main concern users mentioned was the way re-using sub-references works with the "details"-syntax. It is not possible to assign an own name to sub-references, due to the syntax limitations we have to work with. Instead sub-references need to be duplicated in wikitext – but still appear as a re-use (not a duplicate) in reader’s view.

We acknowledge that this leads to a less cleaned-up wikitext than the previous "extends"-syntax promised. We still believe pursuing the implementation of the "details"-syntax for sub-referencing to be an improvement compared to the status quo, which requires laboriously duplicating entire references when re-using them with different details. And in most use-cases – especially when using sub-references just with a page number – sub-referencing will not just clean up the reader’s view, but still reduce the wikitext compared to duplicating an entire reference for using it with different details.

The way re-using sub-references will work requires updating all instances of a re-used sub-reference when changing its details in wikitext. This behaviour is similar to existing work-arounds for re-using references with different details, like {{sfn}} or {{rp}}, which also require updating details of all identical "re-uses". However, the VisualEditor citation dialogue will allow efficiently changing all instances of a re-used sub-reference at once in a single workflow.

Other user feedback mentioned potential issues with bots. We will reach out to communities in the months before sub-referencing becomes available and provide support for updating bots and other tools working with references to mitigate potential issues.

Considering the feedback we received we believe that our solution may not be what some have dreamt of, but given the limitations we need to work with it’s the best way forward to provide value to volunteers. We believe that we can mitigate some of the concerns (e.g. by initially developing sub-referencing without allowing templates inside the "details"-attribute and carefully testing its advantages and disadvantages). Therefore we decided to continue developing sub-referencing with the "details"-syntax.

We will now work on implementing the new syntax and finalizing the VisualEditor solution, as always supported by user testing. Once we are ready we’ll approach projects regarding the pilot wiki rollout. Thank you to all communities which have already expressed their interest and supported us thus far!

Let us know if you have any questions or thoughts. Please be advised that our response times may be slower due to upcoming vacations and sabbaticals in the team. Best --Johannes Richter (WMDE) (talk) 11:57, 31 January 2025 (UTC)Reply

The cautious approach of rolling out an MVP and exploring further, templates inside later, is the right approach. I am sad from an editor pov that there will still be duplication, but agree that prioritizing reader view and improving source integrity/readability with reduced duplication is a net win. Thanks for a thoughtful conclusion on a challenging path forward that is bound to disappoint some people no matter what path is chosen! Shushugah (talk) 01:00, 7 February 2025 (UTC)Reply

I think each of our local communities can consider reaching a consensus to discourage using those templates to resolve the "issues with list-defined references in combination with templates like {{reflist}}"? These issues exist regardless of the sub-referencing proposal; why should they be a reason to give up the better syntax? 慈居 (talk) 09:00, 8 February 2025 (UTC)Reply

The problem is not just with Reflist. Reflist issues stem from it being a non-standard template that defines references. This is a broader problem; for example, on Polish Wikipedia, this is called Przypisy, creating a challenge for users moving across different wikis. Many templates are used unnecessarily, leading to cross-wiki UX problems, as well as issues with translations, translation software, and various editing tools — VisualEditor being just a major example. We could have better editing tools if we simply used standard elements more often.

So, the real issue isn’t the Reflist template itself but the practical difficulties of reusing references with detailed citations. We need the ability to define, copy, paste, and refine references easily — without unnecessary hurdles. Currently, when you copy and paste an sfn template, you can either leave it as-is or modify its details (e.g., change the page number). The same will apply to <ref details="page 1"> — allowing for easy definition and modification in a similar way. This will make editing more accessible, particularly for occasional editors as there will be a GUI for that. It's also easier for wikicode editiors too because it's just one extra attribute to learn and it will be the same on all wikis (which I think is crucial here). Nux (talk) 13:39, 8 February 2025 (UTC)Reply

If the problem can be resolved on the community side, e.g. by encouraging use of standard elements for referencing, why should we give up naming subreferences at all? I agree that the new syntax (<ref details="page 1">) brings convenience for both Wikitext and VE editors. But the old syntax (<ref extends="Miller">page 1</ref>) is as simple as the new syntax with only one extra attribute, and allows naming subreferences. 慈居 (talk) 21:50, 8 February 2025 (UTC)Reply

@慈居 while it will look duplicated in code it won’t look duplicated for a reader which is a win compared to regular duplication of references that simply show up twice. Shushugah (talk) 22:05, 22 February 2025 (UTC)Reply

To me editorial experience also matters. Subreferencing is indeed a win for both readers and editors, it's just I need something better. 慈居 (talk) 08:35, 23 February 2025 (UTC)Reply

I might be opening up a can-of-worms, but given that both syntaxes are possible solutions, what about rolling out both? Individual Wikipedias could decide whether to enable one or other the other on a policy level, the same way other citation variants are.

There is existing citation variation (subject to policies of each Wikipedia) and this will continue to co-exist with other forms. I am even in favor of standardizing on a technical level but that's a separate conversation that won't begin or end with sub-referencing. Shushugah (talk) 08:55, 25 February 2025 (UTC)Reply

For me it's always better to have more choices, perhaps since I don't have any concerns developers would have. It'd be nice for me to have a template-free inline citation method, for example. I hesitate to say so for the two syntaxes for subreferencing, though. 慈居 (talk) 13:44, 25 February 2025 (UTC)Reply

No, no, no, please no. That will only create more chaos. Also, adding and supporting a feature like this in the future is not free; in fact, it can be very expensive. Nux (talk) 17:43, 25 February 2025 (UTC)Reply

TL;DR: "We don't want to actually fix Visual Editor's brokenness, instead we're constraining ourselves to try to work around it. So we're abandoning the design that people worked out over several years of discussion in favor of a hack we hope won't also break in VE or confuse non-technical editors into breaking articles." Sigh. Anomie (talk) 00:38, 2 March 2025 (UTC)Reply

Again, what's wrong with <ref name="Miller" details>page 40</ref>? Nardog (talk) 11:35, 2 March 2025 (UTC)Reply

@Nardog Two things:

1. When you edit a section code: Can you define a 1st "Miller" ref with your syntax?
2. When you edit with VE: How would you define the 1st "Miller" ref?

Nux (talk) 20:33, 2 March 2025 (UTC)Reply

Just like any named reference is defined already. Nardog (talk) 23:22, 2 March 2025 (UTC)Reply

@Nardog Can you show me how? I cannot think of any way to define ref with details using syntax you shown above. Not just by editing one section. Nux (talk) 01:32, 4 March 2025 (UTC)Reply

I believe these are issues which deployment of subreferencing feature should motivate us to resolve, not what forbid deployment of a more "cleaned-up" syntax as Johannes Richter calls it. 慈居 (talk) 07:23, 3 March 2025 (UTC)Reply

I'm glad you're moving forward. The approach you laid out seems sensible to me. Thanks for the team's work on this and the planned improvements. Ganesha811 (talk) 15:46, 13 March 2025 (UTC)Reply

Are there examples of what this new proposal would look like? Jc3s5h (talk) 12:02, 17 March 2025 (UTC)Reply

Hi, @Jc3s5h, we created some test pages on the beta wiki, see for example https://en.wikipedia.beta.wmflabs.org/wiki/CiteDetailsTests. This is of course still work in progress, but might help with the visualisation. Best, Svantje Lilienthal (WMDE) (talk) 14:57, 21 March 2025 (UTC)Reply

Works great :). I added a slightly different use case for working within a single section: In section definition and usage. Nux (talk) 22:58, 21 March 2025 (UTC)Reply

I tried to create an example page containing references as a sub-page of a of my user page on en.wikipedia.beta.wmflabs.org and received an error message:

[Z-qD9fyiAKx4FVbmarBNswAAABU] /w/index.php?action=submit&title=User:Jc3s5h/Referencing_example MediaWiki\Extension\AbuseFilter\Filter\FilterNotFoundException: Filter 63 does not exist</blockpage>

Jc3s5h (talk) 12:03, 31 March 2025 (UTC)Reply

I was able to create it as a draft: Draft:Moderator (town official). It does not yet have the detail parameter added, I'm waiting to see if anything happens to it before I do more work.Jc3s5h (talk) 12:13, 31 March 2025 (UTC)Reply

I have modified the draft to include the details parameter. Jc3s5h (talk) 15:24, 1 April 2025 (UTC)Reply

Thanks, @Jc3s5h! I take it the error you posted above did not occur again after your second attempt to include the details parameter, or did it? Let us know if you have further feedback on the feature. Lina Farid (WMDE) (talk) 14:13, 10 April 2025 (UTC)Reply

I guess the error message I mentioned was because I tried to create an article, rather than a draft article. My draft has just sat with no attention since 31 March 2025. I speculate that little or no attention has been given to the concept of someone not on the staff of beta.wmflabs.org creating an article. Jc3s5h (talk) 14:28, 10 April 2025 (UTC)Reply

I have added some examples of the Subref template, and added some complaints about it to the talk page for the Subref template Jc3s5h (talk) 15:23, 10 April 2025 (UTC)Reply

Attributes cannot contain tags. Wikitext can. So what will be interpreted as wikitext shouldn't be in an attribute. Nardog (talk) 13:22, 13 April 2025 (UTC)Reply

The old ‎<ref extends="foo">...‎</ref>} syntax allowed use of CS1 templates to get standardized formatting of, e.g., |author= (when different for chapter), |section=, |section-link=, and links for page numbers. It looks as though the VE tail is wagging the wiki dog. -- Chatul (talk) 14:30, 30 April 2025 (UTC)Reply

Hi @Chatul, thanks for your feedback. It should be possible to use CS1 templates in sub-references using wikitext, e.g. like this [10] (the template is a demo created by a community member [11]). Johannes Richter (WMDE) (talk) 10:33, 5 May 2025 (UTC)Reply

@Johannes Richter (WMDE), apologies for the late reply. List-defined references created using the <references></references> also do not work in the VisualEditor. From the VE (even with the native wiki syntax), list-defined references cannot be added, removed, or replaced. Removing all usages of a list-defined reference will create a large red error message that cannot be resolved from within the VisualEditor. There is interest on en-wiki for replacing the {{reflist}} template on all articles with list-defined references because it does allow the VisualEditor to display and modify existing list-defined references. If the VisualEditor fully supported the native wiki syntax for LDR, I think most wikis would deprecate the "reflist|refs=" kind of format.

I brought this technical barrier up 2 years ago on this talk page, wrote a demonstration article, and created a bug report on Phabricator. I received the response "I hope you will find a solution soon." which was very confusing as I am not working for the WMF or developing any aspect of the MediaWiki software, Rjjiii (talk) 14:52, 14 June 2025 (UTC)Reply

Hi @Rjjiii, thank you for raising this issue again! We are aware that list-defined references are still an issue with VE – especially when using {{reflist}}, but even when using <references></references>. And thanks for your detailed bug report describing the different issues. We have decided to concentrate our focus on sub-referencing for now in order to finally implement this feature. Given that our new "details"-syntax no longer requires list-defined references, sub-referencing will no longer lead to additional problems for VE users.

Once sub-referencing is implemented we will continue to work on technical improvements for references, as decided by the dewiki community in the 2024 survey on the next WMDE Technical Wishes focus area [12]. We will likely look at some smaller and medium-sized improvements to referencing initially (rather than immediately picking up a project as big as sub-referencing). The VE shortcomings for list-defined references might be a good issue to solve (regarding <references></references>, solving the issue of references within templates like {{reflist}} would be very difficult according to our devs). I can't promise anything, as we are currently exploring different ideas and bug reports already submitted by our community, but I'll make sure your ticket is on our list of possible improvements. Johannes Richter (WMDE) (talk) 10:06, 16 June 2025 (UTC)Reply

Gotcha. Thanks for taking the time to explain, and I wish you luck on rolling sub-referencing out, Rjjiii (talk) 04:51, 29 June 2025 (UTC)Reply

Please see https://en.wikipedia.beta.wmflabs.org/wiki/CiteDetailsTests#Invalid_syntax

I created a reference tag with an invalid name (it has spaces in the name but no quotation marks). I get an error message, which is good, but the error message has incorrect text: "Cite error: Invalid parameter in <ref> tag". Tags have attributes, not parameters. On the English Wikipedia, the same invalid format produces "Cite error: The <ref> tag has too many names (see the help page)."

Has this system gone through any kind of QA or unit testing to ensure that it works per the documentation, and that the error messages match the documentation? Or is that what we are being asked to do? Jonesey95 (talk) 13:28, 30 April 2025 (UTC)Reply

Thanks for testing @Jonesey95! The feature is still in development, which means the documentation is going to change while we keep improving sub-references. Details like cite error messages might also still need to be adapted. We are currently asking users to do some testing on betawiki and leave their feedback to make sure we are moving in the right direction with the feature in general (do users understand how to use the wikitext? do they prefer templates within sub-references? are we missing important features?). Cite error messages and similar issues will be fixed before implementing sub-referencing on any production wiki. Johannes Richter (WMDE) (talk) 10:14, 5 May 2025 (UTC)Reply

Sub-referencing has been deployed to German Wikipedia today as our first pilot wiki. We will continue to improve the feature based on community feedback. We would like to hear your thoughts on the following question:

We've noted in our FAQ that there was mixed feedback about the idea of using templates in sub-references. Our project pages currently just show simple examples without templates, but it is possible to use templates in wikitext and VisualEditor, both in main- and sub-references. Some community members already created a sub-referencing template on betawiki for testing. Example for sub-references with templates:

According to scientists, the Sun is pretty big. In fact, it is very big.<ref name="Miller" details="{{Subref |page=23}}">{{Cite book |last=Miller |first=E. |title=The Sun |publisher=Academic Press |location=New York |date=2005}}</ref> Take their word for it.<ref name="Miller" details="{{Subref |page=48}}" />

== Einzelnachweise ==
<references /> <!-- or {{Reflist}} -->

If details=..." just contains a page number, a sub-ref template probably doesn't seem needed, but if there are more complex details (e.g. edition, chapter, page number, quote...) such a template might be useful? It's of course possible to use existing templates like {{cite book}} in sub-references as well, although some templates might expect parameters (e.g. the title) which you usually wouldn't use in details=...".

Some VisualEditor users mentioned that they don't like the input field for sub-references and would prefer filling out a template. Currently VE users need to click "insert" above the input field and browse for a template themselves, which then opens the template dialog, if they don't want to use the input field.

What are your thoughts on using templates in sub-references? Which parameters should a sub-reference template provide? Should we improve VisualEditor support for templates in sub-references, e.g. by allowing projects to define default templates for the VE sub-ref dialog, similar to MediaWiki:Cite-tool-definition.json for the VE reference dialog?

Feel free to test sub-references and templates on betawiki, e.g. using this example page. Thanks for your feedback! Johannes Richter (WMDE) (talk) 16:21, 22 September 2025 (UTC)Reply

Personally I wouldn't want to use templates for details. I think templates complicate things too much in cases where cite template is not generated and details will not be generated. The GUI for templates has a lot more to go before being actually useful for com0plicated templates. Like repeatable groups of parameters so that you don't see tens of lastname1, lastname2, but actually add a repeatable author: [firstname], [lastname]. Toggled groups of parameters (checkbox/accordion to show a group of parameters). More types of parameters like boolean/radio etc...

But, it's nice to have a longer box to add a quote or a section title. Nux (talk) 18:57, 22 September 2025 (UTC)Reply

Thanks for sharing your thoughts! I agree that the template dialog might be confusing if there are too many parameters – or even prompt users to fill out the wrong fields, depending on which information stays in the main reference and what's moved to the sub-reference? We're already seeing lot's of different sub-reference use cases on German Wikipedia which are not (just) about using a different page number, covering all of these with a single sub-ref template might be quite hard.

On the other hand: The large majority of use cases could be covered with a simple template offering parameters for details like chapter, page number and quotes, which shouldn't be too hard to use? Johannes Richter (WMDE) (talk) 17:43, 25 September 2025 (UTC)Reply

I like the idea of having simple dialogs for templates in sub references, since it would make it much easier for things like page numbers and chapter numbers to have consistent formatting (no Pg. vs Page vs pp. vs...). I imagine the fields you've listed in the screenshot above would cover the vast majority of detail cases. TROPtastic (talk) 23:23, 6 October 2025 (UTC)Reply

Sub-referencing is now deployed to our first pilot wiki and already used on more than 400 pages [13]. We are currently fixing known issues (e.g. automatically merging identical sub-references in the reference list in reader view) and will reach out to other potential pilot wikis in a couple of weeks. Please let us know if your project is interested at piloting. There are some projects we currently cannot include as a pilot wiki because we are still working on sub-referencing issues with templates like {{reflist}} in VisualEditor, but if your project mostly uses <references /> we would be happy to talk! Johannes Richter (WMDE) (talk) 13:16, 25 September 2025 (UTC)Reply

On plwiki we try to replace templates containing refs with <references> (search shows about 65k articles with </ref>..</references>). So I think you could count plwiki in.

It would be nice to have the ability to test it during our mining edition next week. Maybe people would be willing to test and discuss problems during lunch. Some tech people will be present, so it would be possible to explain how this works to a larger community in person (which is sometimes easier). Nux (talk) 15:23, 25 September 2025 (UTC)Reply

Thanks for the quick response! Sub-referencing is currently available on dewiki, testwiki and betawiki. Would one of those projects be sufficient for testing purposes or would you actually like us to deploy to plwiki next week? We are currently observing dewiki to make sure there are no unintended side-effects of sub-referencing and (as mentioned above) still have to fix some known issues, but I can discuss with the team if deploying to another wiki so quickly would be possible if that's what you meant. The knowledge mining event sounds really interesting, is there anything we can do to support the discussions? Johannes Richter (WMDE) (talk) 17:26, 25 September 2025 (UTC)Reply

Hi, I read through the current issues list and I don't think those are blockers for releasing on plwiki. I mean, the lack of merging might be a bit annoying, but if it's going to be fixed soon-ish, then it's fine. I can write a summary of gains and things to come on plwiki (what to expect in near future). So yes, I think early releases to plwiki should be fine, but if you want to wait until the feature is more mature, I'll understand that too. Nux (talk) 06:48, 28 September 2025 (UTC)Reply

@Nux thanks for your interest! I've talked with our product manager, if your community wants to pilot sub-referencing, we are fine with releasing to plwiki this week (this could happen outside the regular deployment train). Should there be a community discussion?

I've realized I made a typo in my initial message: There are currently VisualEditor issues with sub-references and reflist-style templates even for the default usage (replacing <references />), not just when it comes to list-defined references. If you want to try it in my sandbox [14]: While wikitext & reader's view are working fine with {{reflist}}, it's currently not possible to edit a main reference in VE if it has details attached (it's working if the main reference doesn't have details [15]). Given how many articles are using pl:Szablon:Przypisy I believe it would be risky to release to plwiki, even if editors are instructed that using sub-references currently requires <references /> in order to avoid deteriorating the user experience for VE users. With that in mind, it might be better to wait until we're done making sub-referencing compatible with reflist, unless your community really want's the feature in it's current state. --Johannes Richter (WMDE) (talk) 09:36, 29 September 2025 (UTC)Reply

It seems to be working fine on testwiki: testwiki:User:Nux/test ref - strony i sekcje (I can change the date in Miller's ref).

I'm still convinced that since you already deployed it to dewiki, it will all be fine... But just to be sure, I asked the plwiki community for their opinion. I hope the survey will be flooded with positive votes, but you never know. I'll see and let you know how it goes. Nux (talk) 23:23, 29 September 2025 (UTC)Reply

@Nux many plwiki articles currently use pl:Szablon:Przypisy while there's no such template on dewiki, all dewiki articles are using <references /> or <references></references>.

If a wikitext user on plwiki introduces sub-referencing without changing from pl:Szablon:Przypisy to <references /> or <references></references> (similarly if a VE user does so, usually without even noticing if the article uses the template or not), it will lead to some errors:

Example.<ref name="Example" details="page 2" />
== References ==
{{Reflist|refs=
<ref name="Example">Main ref content</ref>
}}

Currently leads to a Cite error in the reader's view instead of showing the main reference content. And VisualEditor users will a warning instead of the main ref content: "These details are linked to a missing reference. Please remove them from the page or fix the issue in source mode."

Example.<ref name="Example" details="page 2">Main ref content</ref>
== References ==
{{Reflist}}

Works in reader's mode, but also shows the mentioned warning instead of the main ref content to VE users.

We can go ahead and deploy to plwiki if your community is fine with changing all articles using sub-referencing to <references /> or <references></references> until we've fixed the mentioned issues and made sub-referencing compatible with templates like reflist. That might require cleaning up pl:Kategoria:Strony z zepsutymi przypisami every time a VE user introduces sub-references to an article using pl:Szablon:Przypisy for the weeks or potentially a few months until sub-refs are working with such templates. --Johannes Richter (WMDE) (talk) 09:31, 30 September 2025 (UTC)Reply

Actually I think this is not a problem with {{reflist}}. I think this is larger problem, see: phab:T406002 (I added this today). It seem like there is a problem with any ref defined in text. Many active editors don't use VE so I think even this is not a blocker, but it is a major issue.

And as for pl:Szablon:Przypisy - really, don't worry about it. I'm an author of cleanup tool (wp_sk). It's the most popular gadget on plwiki (excluding HotCat). Probably all active editors use it. It automatically changes {{Przypisy}} → <references></references> as needed. If we will need to change the template in more cases then it is possible too (though probably not if this is avoidable). Nux (talk) 11:04, 30 September 2025 (UTC)Reply

Sorry, I think I need to call it. It was a bit of a crazy idea to get this fast-tracked to plwiki before the event. I see less enthusiasm in our current discussion than I expected. The vote is not going badly, there is support, but people are raising concerns about currently known issues. With that results I think it would be too early to release this week. Maybe that is for the best, I don't want to burn this feature. We can wait until at least you had your Crème Brulée with berries :). I'll try to remember to let you know how our vote ended. Nux (talk) 19:04, 30 September 2025 (UTC)Reply

Thanks for finding and reporting the bug! Our developers are already working on it. We noticed that the bug doesn't appear if you're changing both the main reference and the details which might be a reason why the bug wasn't caught earlier.

Let's revisit piloting after we've solved more of the current issues. I'll be out of office for most of October (so are some other team members), so it's probably best to continue the discussion in November :) Johannes Richter (WMDE) (talk) 14:22, 1 October 2025 (UTC)Reply

@Johannes Richter (WMDE) Hello, after a break. We are {reflist}-free on plwiki. This time removed all of them from everywhere (not just from new stuff); our template no longer supports adding refs to it. In an official vote to use subrefs on plwiki, the feedback was mostly positive, with only some concerned about bugs, which I think no longer a thing. I noticed e.g. T406002 is resolved, so I think it's safe to say we're ready when you are :). The Polish Wikipedia is ready for being a pilot wiki. Let me know if you need me to do anything else. And of course, let me know when/if you plan to add new pilot wikis and when we can begin adding subrefs (I can announce it on plwiki or leave that up to you or I can translate a message for you). Nux (talk) 00:26, 18 January 2026 (UTC)Reply

Thanks for your continued interest in piloting and offering your support with the announcement @Nux! We are currently thinking about sub-referencing deployment (preliminary plan without fixed dates in phab:T414094). We just need to check with the WMF Content Transform Team about their parser unification plan for large wikis. If there're no issues from their side, we could deploy to plwiki very soon. I'll let you know when we can set a date and appreciate your offer to translate the announcement message! Johannes Richter (WMDE) (talk) 10:58, 19 January 2026 (UTC)Reply

I've left a note about the feature on English Wikipedia's Village Pump (Technical). Rjjiii (talk) 21:03, 25 January 2026 (UTC)Reply

@Nux I will do the official announcement beginning of next week, but as a heads-up: We are ready to deploy sub-referencing to plwiki and aim to do so mid-February (probably February 17). Johannes Richter (WMDE) (talk) 16:42, 28 January 2026 (UTC)Reply

Because everything has to be inside of details="…" I get problems in German Wikipedia with template de:Vorlage:". But I can use single quotes details='…' like in de:Spezial:Diff/260151408 (last change on bottom). Alas, then I cannot mark the text italic or bold or have to remove this markup on conversion. Also, in English Wikipedia according to Manual of Style straight quotes have to be used, see en:Wikipedia:Manual of Style#Quotation characters where you will get unsolvable issues with quotations within a quotation. Then I noticed that comments are not possible^*) and HTML tags, too – I wanted to use superscript as in the source. For now, I have in a not yet published text used the parser function {{#tag:sup|superscripted text}}, but I know there will be some people going nuts about this. Therefore I want to suggest an enhancement of the function, mockup:

<ref name="unique" details>Reference text for detail, but with all the allowed wikisyntax</ref>

I.e. the details tag is empty (details="" should be dealt the same, as it is technically), the actual reference text goes between the ref tags. The outcome should, of course, be the same like it is with the active version.
^*) I did not ask Karl, but assume he ran into the comment issue here: de:Spezial:Diff/260120814/260136345. In my already linked edit de:Spezial:Diff/260151408 I only added ([[Sic!]]) because of this, I would have preferred the decent comment.
— Speravir – 22:47, 29 September 2025 (UTC)Reply

Hi @Speravir, thanks for leaving your feedback. We've chosen the details="..." syntax after years of community consultations as the best approach to balance the needs of wikitext and VisualEditor (read more in our FAQ / this post).

We are aware of the limitations and mentioned workarounds on our project page. The following example works as expected: <ref name="LSJ1" details="[https://lsj.gr/wiki/Ω {{lang|grc|Ω}}]; Zitat: {{&quot;|Sprache=en|Text=The name of the letter was {{lang|grc|τὸ ὦ}} }}.&lt;!-- sic! --&gt;" /> [16]. Noting that VisualEditor users are not affected by these limitations, if they are using characters like " within a sub-reference, it will automatically be converted to ".

We are of course also aware of enwiki's MOS. If people want to use quotations within sub-references and don't like the " workaround, we recommend using templates instead. Some community members already created a test template for sub-references on en-betawiki [17].

Something like <ref name="Miller" details="{{Subref |page=48 |quote=This is a quote}}" /> would show the desired quotation marks in the reader's view (example using the template [18]).

Regarding de:Vorlage:" – if you don't want to use {{" you could also consider creating a redirect for the template using a title without special characters.

PS: You can also use de:WD:Technische Wünsche/Topwünsche/Subreferenzierung to leave your feedback, we're monitoring both pages. Johannes Richter (WMDE) (talk) 11:07, 30 September 2025 (UTC)Reply

Thank you, as well, Johannes.

• “We've chosen the details="..." syntax after years of community consultations”
  Hmpf, if I had been aware of these problems I certainly would have written a regarding message, though admittedly I am almost not active in this area …
• “The following example works as expected: <ref name="LSJ1" details="[https://lsj.gr/wiki/Ω {{lang|grc|Ω}}]; Zitat: {{&quot;|Sprache=en|Text=The name of the letter was {{lang|grc|τὸ ὦ}} }}.&lt;!-- sic! --&gt;" />”
  Oh, very interesting! So, apparently, because it’s a new feature just the help page needs an according informational update regarding use of HTML entities for critical characters. (Update 23:36, 30 September 2025 (UTC): Ah, you’ve recently already updated the page in regards to the feature.)
• “If people want to use quotations within sub-references and don't like the " workaround, we recommend using templates instead.“
  Just as a side note: de:Vorlage:" is thought to be exactly this. (For other people, Johannes knows this all in this sentence, of course. What I forgot above: Vorlage is template in German.)
• “if you don't want to use {{" you could also consider creating a redirect for the template using a title without special characters.”
  I have actually already considered this an option, but there sone influential people allergic to template redirects.
• “PS: You can also use de:WD:Technische Wünsche/Topwünsche/Subreferenzierung to leave your feedback, we're monitoring both pages.”
  Oh. Where I could have everything written in my natural language … and you’ve answered in your’s, too.

— Speravir – 23:30, 30 September 2025 (UTC)Reply

I've added a note at de:Hilfe:Einzelnachweise [19] about the issue with " Our dewiki project page mentions the issue as well [20] (just like the metawiki project page).

Let's discuss the specific issue with de:Vorlage:" at de:WP:VWS, most templates fortunately don't include special characters like ".

Upside on discussing your issue on Metawiki: Community members on other wikis can learn from it once we are closer to deploying to other wikis :) We are happy to answer to questions and feedback on both our dewiki and metawiki project pages (and in any other local discussions we're involved in of course). Johannes Richter (WMDE) (talk) 14:46, 1 October 2025 (UTC)Reply

OK, then! — Speravir – 22:29, 1 October 2025 (UTC)Reply

I tried out the new sub reference feature, and it seems great! It will be very useful to reuse references with different pages, quotes, etc. as long as Wikis put some work into maintaining formatting consistency within the free for all details field. I also like how it automatically converts existing references once you add details, without needing to add a sub reference and then delete the old reference. I wasn't aware of discussions surrounding the syntax, but I was less active on the "back end" wikipedia pages in the past.

The one issue I encountered is that I couldn't "Add details" to these references on the beta wiki:

<ref>[https://www.hunton.com/media/publication/3094_Hunton_Guide_to_the_EU_General_Data_Protection_Regulation.pdf The Proposed EU General Data Protection Regulation. A guide for in-house lawyers], Hunton & Williams LLP, June 2015, p. 14</ref>

<ref>{{Cite web|url=https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/|title=What is personal data?|date=January 2021|access-date=22 July 2019|archive-date=24 July 2019|archive-url=https://web.archive.org/web/20190724112940/https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/|url-status=live}}</ref>

However, the Add details button did appear for these other references, so I don't think it's an intentional restriction.

<ref name="eur-lex.europa.eu">{{cite web|access-date=21 March 2018|title=EUR-Lex – 32016R0679 – EN – EUR-Lex|url=http://eur-lex.europa.eu/eli/reg/2016/679/oj/eng|website=eur-lex.europa.eu|archive-url=https://web.archive.org/web/20180317035823/http://eur-lex.europa.eu/eli/reg/2016/679/oj/eng|archive-date=17 March 2018|url-status=live}}</ref>

While I can understand that not enabling this functionality for basic references may be a result of a technical limitation (which would be too bad for the many basic references on en wiki, but acceptable), it is weird that some web cites show the Add details button and others do not. TROPtastic (talk) 05:06, 3 October 2025 (UTC)Reply

Once you copy (reuse) the ref you can add details to it. This is weird though. Even when you add details in code editor you will not be able to edit them in VE... seems like a bug. Nux (talk) 06:38, 3 October 2025 (UTC)Reply

I understand the first part might be intentional (only show details button if ref is copied), but how will you know if it is copied when user is editing a section (possible on mobile). I think that restriction (ref being used more then once) is potentially more harmful than useful. Nux (talk) 06:46, 3 October 2025 (UTC)Reply

Hi @TROPtastic the issue is indeed like @Nux explained: We aren't showing the "add details"-button unless a reference is already re-used - if there's only one reference you should just edit that reference to add additional information. Showing the button for single-used reference might prompt VE users to turn it into a sub-reference even if there's no need to do that.

@Nux I'm not sure how/if section editing is an issue. You should be able to insert re-used references from other sections if you use the citation button -> re-use tab. After inserting the reference you can proceed to add details. I also don't think there's an issue detecting re-uses while editing a section, at least I couldn't confirm that when editing a section on mobile with a reference only re-used in other sections.

We have tested an option to allow re-using with different details in the re-use tab [21], but user testing hasn't shown convincing results that users fully understood that option. Let us know if you have other ideas, we are looking for additional input on how to improve the VisualEditor experience for sub-referencing. Johannes Richter (WMDE) (talk) 09:39, 3 October 2025 (UTC)Reply

Thanks for the clarification @Johannes Richter and @Nux, I wasn't aware that a reference needed to be reused to show the Add details button. It makes sense that single-used references should not be converted to sub-references.

The current workflow to re-use a ref with different details seems intuitive to me. You can easily re-use a sub-reference and change the details if you want, or re-use the main reference and add details to turn it into a new sub-reference. TROPtastic (talk) 09:51, 3 October 2025 (UTC)Reply

Oh, ok it does work when a single ref has name and details. It doesn't work in VE when a name is not added... So that should work in most cases. I'm not convinced it is needed, but I understand why it is done like that. Nux (talk) 09:56, 3 October 2025 (UTC)Reply

The m:SUBREF syntax ‎<ref name=foo details="bar" /> does not support templates, unlike the original ‎<ref extends=foo>bar‎</ref> proposal. This makes it more difficult to have standard rendering of, e.g., quotations, in subreferences, much less proper metadata. There should be some way to use a template within a subreference. -- Chatul (talk) 21:48, 10 November 2025 (UTC)Reply

@Chatul templates should work fine (or it did last time I checked). See: #Templates used in sub-references. Nux (talk) 22:08, 10 November 2025 (UTC)Reply

Yes indeed, templates within details are possible and we've already seen lots of different usecases on our pilot wiki (German Wikipedia). One example: [22]. Johannes Richter (WMDE) (talk) 12:26, 11 November 2025 (UTC)Reply

Hi, I noted that if you go and edit an existing reference with details, click the "Replace citation" button, and try to create some reference via the "Automatic" or "Manual" tabs of the "Replace citation" dialog, it inserts a Cite template as details of the existing reference. Samoasambia ✎ 19:58, 1 December 2025 (UTC)Reply

Thanks for testing sub-references and noticing this, we are looking into it: phab:T411466. Johannes Richter (WMDE) (talk) 16:24, 2 December 2025 (UTC)Reply

Not an immediate feature to add, but somewhere down the line, could this be used to implement shortened footnotes, which are used by Chicago style footnotes and English Wikipedia's shortened footnotes?

Here is part of a comment I left in discussion about the complex shortened footnote citation templates on English Wikipedia:

It would be much easier to deal with these if the underlying software handled it; then we wouldn't have to take the jigsaw approach to connecting shortened footnotes. WMF wouldn't even have to deal with citation styles, they could just format it something like <ref name="Author-DATE">Author (DATE). ''Title: Subtitle''. Publisher. <at>page.</at> ID:####.<short>Author date, <at>page</at></short></ref> Named references could give just the "at" value like <ref name="Author-DATE" at="p. 7"/> or <ref name="Author-DATE" at>p. 7</ref>. Then the software could give the full citation details and in-source location for the popup (which is probably how most people see our citations), while auto-formatting the list of footnotes to print the full citation details for the earliest footnote and use shortened footnotes on later uses. Templates could largely hide the complexity.

Rjjiii (talk) 21:02, 25 January 2026 (UTC)Reply

Thanks for the suggestion. One of our design principles was keeping the wikitext syntax close to the existing reference syntax in order to avoid adding too much complexity. It might be possible to support the desired outcome case using templates but we've chosen not to add additional parameters to keep it simple. Our main focus for further development is on improving the reader view (reference list and reference previews) and improving some VisualEditor use cases (including full {{reflist}} support). Johannes Richter (WMDE) (talk) 16:39, 28 January 2026 (UTC)Reply

In September 2025 we deployed sub-referencing to German Wikipedia to make re-using references with different details easier. Thanks for piloting and helping to improve the feature!

We recently published our insights and next steps with sub-referencing in our report. Some highlights:

• Over 6,000 Wikipedia articles use the new feature, with a total of over 15,000 sub-references created to date.
• There are both experienced editors in featured articles (e.g. de:Explosion des Oppauer Stickstoffwerkes) and relatively inexperienced VisualEditor users (e.g. in de:Schmerzhafte Muttergottes (Guido Cagnacci)) using the feature. The majority of all sub-references (approx. 90%) are created in wikitext, yet over 300 editors have used the function in VisualEditor alone.
• Workarounds like <ref name="Miller" /><sup>p. 44</sup> (in the reader view ^{[1] p. 44}) have been replaced entirely by sub-referencing, which means that the complete reference information – including the page number – is now visible in both the reference list and in Reference Previews.
• Sub-referencing is used with lots of different citation details – predominantly page numbers, but also details such as chapters, paragraphs, quotes or video / audio timestamps.

What has happened since September?

• We ensured that re-used sub-references actually appear as re-used in the reader view and in VisualEditor.
• We've made some cosmetic changes to the reference list: Initially, multi-line sub-references (e.g. quotations) were not displayed ideally, and two-digit sub-reference numbers were not indented correctly.
• In VisualEditor, we have provided a feature to choose whether changes to re-used sub-references should affect all uses of the same sub-reference or only the one currently edited.

What's next?

• We will deploy sub-referencing to additional pilot wikis next week: Polish Wikipedia, Swedish Wikipdia and seven smaller wikis (phab:T414094). All of these projects have been notified in advance.
• We are working on technical adjustments to make sub-referencing usable in all wikis that use variants of the {{Reflist}} template.
• We are continuing to address community feedback: Among other things, we are currently exploring various ideas for visually improving reference lists with lots sub-references (e.g. de:Liste der Straßen in Bad Honnef#Einzelnachweise und Anmerkungen).
• In addition to sub-referencing, we are looking at other reference-related improvements: We are considering general improvements to Reference Previews or solving issues with automatically created reference names in VisualEditor – there will be announcements and community consultations on this in the near future.

More about sub-referencing on our project page, more about our learnings and next steps in our report. All the best from WMDE Technical Wishes! --Johannes Richter (WMDE) (talk) 15:21, 9 February 2026 (UTC)Reply

As of today, sub-referencing is deployed to the following wikis: dewiki, plwiki, svwiki, dewikivoyage, alswiki, frrwiki, fiu-vrowiki, gpewiki, rmwiki, kncwiki. Thanks for piloting the feature! Johannes Richter (WMDE) (talk) 16:10, 24 February 2026 (UTC)Reply

Johannes Richter (WMDE) any estimate of when this will be available on enwiki? RoySmith (talk) 17:42, 2 March 2026 (UTC)Reply

@RoySmith thanks for asking! Preparing sub-referencing for {{reflist}} will still take a while, at least 2+ months according to our engineers (relevant tickets: phab:T397501, phab:T417612, phab:T395083). We'll then deploy to a couple of smaller / medium-sized wikis using reflist to make sure there are no issues before we're ready to deploy to enwiki. While there are no issues in reader's view and in wikitext, VisualEditor users currently cannot edit a sub-references' main reference if {{reflist}} is used (regardless of whether the main reference is list-defined or inline).

Plwiki agreed to use a bot to replace their reflist-version {{Przypisy}} with <references /> once sub-references are added to an article (detected by our tracking category) to make sure there are no issues for VisualEditor users, following our misunderstanding (we mistakenly believed the template was deprecated when we deployed to plwiki). That might be an approach other large wikis could consider as well if it proves to be working. Johannes Richter (WMDE) (talk) 18:11, 2 March 2026 (UTC)Reply

The sub-referencing does not have the exact look that the workaround <ref name="Miller" /><sup>p. 44</sup> provides. Of course we don't like this workaround because the correct style would be something like ^{[1: p. 44]}. Do you plan (maybe in the future) to provide options for alternative styles, such as an option to show the detail inline? 慈居 (talk) 20:14, 3 March 2026 (UTC)Reply

Hi @慈居, we currently don't have plans to provide such an option, but we are looking at potential improvements to the way sub-references are displayed and already received some other feedback about allowing different footnote number styles. While gradually releasing the feature to more wikis, we'll continue to listen to community feedback and observe if there are different needs sub-referencing should cover as well. I've noted your feedback on our list of suggestions to evaluate while exploring potential improvements.

We would need to do some user tests of course to investigate how readers would interact with footnote markers like ^{[1: p. 44]}. It feels likely to me (just as with the existing workaround ^{[1]p. 44}) that the average reader doesn't really understand this is a page number – and even if they do, what's the advantage of displaying it outside of the Reference Preview when you can easily show the main reference and details like the page number in the same pop-up? Johannes Richter (WMDE) (talk) 10:52, 4 March 2026 (UTC)Reply

Different number syles, good to know! About the accessibility concerns in your link, perhaps there should be option for bigger text (e.g. no superscript) for the inline citation. Text in infoboxes, navigation templates, etc. is already small, so I often avoid citing something there (see ko:토이에르 방 for example).

My defense for the [1: p. 44] style is simple: the more you put below, the more often you have to go there while reading. With this style, often you remember what the ref 1 is, so you don't need to hover the cursor over [1]p. 44. This will significantly reduce inconvenience and accessibility challenge for a wide range of users. (+++ I have never seen the current sub-referencing style used elsewhere; is it actually used somewhere else?)

Slightly off-topic, some books and articles that are considered classical use different reference numbering (not details numbering! so this is not strictly on-topic) than arabic numbers; so [Miller: p. 44] instead of [1: p. 44] and for more than one authors, say Hardy and Wright, [HW: p. 44]. If I write a book for Wikibooks, I'd be glad to use the style I prefer! 慈居 (talk) 20:12, 4 March 2026 (UTC)Reply

Thanks for sharing your thoughts. I feel like what you've described about remembering ref 1 is probably more likely to happen while editing an article than something casual reader's would do? Nevertheless something we'll consider when evaluating sub-reference footnote number styles.

Not sure if/how something like ^{[Miller: p. 44]} could ever be meaningfully achieved without introducing too many complications, but I've noted it as well (note that this might cause confusion with ref group footnote numbers, e.g. ^{[footnote 1]}).

Sub-referencing is loosely based on Ibid. and similar citation styles that refer to a previously used source with another page number. Johannes Richter (WMDE) (talk) 17:14, 9 March 2026 (UTC)Reply

I'm no expert but we could get some idea from here and from the "mode" attribute of the "gallery" tag.

I believe it will be sufficient for us to be able to give numbering to the references by, say the "name" attribute.

Anyway, it is important to me to implement common citation styles out there to meet diverse needs and purposes. No sytles are perfect and it should be up to the community to decide whether to use them or not. Different projects will have different choices. Wikibooks can benefit from being able to create a book of unique style and Wikisource from using the citation style used in the original literature. 慈居 (talk) 03:25, 12 March 2026 (UTC)Reply

Hi. I doubt most users would understand the Harvard notation, e.g. [Miller: p. 44]. That notation works fine for technical and scientific publications where you know (or should know) the authors, and in many cases you know which book Miller wrote on the subject you are reading about. So I don't think that should be default appearance. But it should be possible to make a gadget for that. If/when MediaWiki supports the attr() function, then you can expose any attributes even without JS. So if you had <sup class="reference" data-name="Miller2024" data-details="p. 123">, then you can use those data attributes to rewrite the contents of the ref-link with CSS. At the moment you could probably do that with JS. Nux (talk) 23:39, 12 March 2026 (UTC)Reply

I think whether readers understand depends pretty much on the context. It is likely that most readers understand what it means to say "Miller (2024: p. 44) found that ..." or "See the book [Miller: p. 44]". Unlike arabic numbered references, it is more likely that they know this is a reference rather than an explanatory footnote.

The new style brings equally serious confusion, say by using two-level numberings and lists. I believe use of existing styles will help reduce possible confusion. I agree with you that the harvard-like style shouldn't be the default style but you should implement and allow that alternative style.

I believe gadgets should be the last resort. From my experience this will lead to a new template, which is difficult to handle in VisualEditor. Also it will be difficult to translate articles using this gadget. 慈居 (talk) 01:57, 13 March 2026 (UTC)Reply

As for problems with the reflist-like templates, if we can't handle say recursive use of templates I think it is better to do nothing about it. The reflist template is not compatible with VisualEditors even without subreferencing. Please do not give the communities another reason to keep the template unless the problem can be solved completely. 慈居 (talk) 09:15, 6 April 2026 (UTC)Reply

We are aware of existing issues with {{reflist}} and VisualEditor, but sub-referencing would add new ones that can lead to some unpleasant edge cases which we have to resolve (phab:T397501). We are making good progress currently. While working on reflist-compatibility we are also continuing the deployment process to some wikis not using such a template: phab:T420938. Johannes Richter (WMDE) (talk) 13:49, 6 April 2026 (UTC)Reply