Talk:WMDE Technical Wishes/Sub-referencing

(Redirected from Talk:WMDE Technical Wishes/Book referencing)
Latest comment: 5 days ago by Johannes Richter (WMDE) in topic Request for feedback

Re-use in VisualEditor

edit

Hi! I found no mention of it: as it can be seen on the screenshot, if you try to re-use a subreference, all you see in the popup is the “sub-” part – pp. 23–26, § 42 or something similar. This is not very useful, I hope you plan to fix this before the release. —Tacsipacsi (talk) 15:00, 28 July 2024 (UTC)Reply

Thanks for your feedback @Tacsipacsi, we are aware of this issue, that's indeed something we want to improve. --Johannes Richter (WMDE) (talk) 05:41, 31 July 2024 (UTC)Reply

Same sub reference

edit

Tried in "Hella" article in beta. When extending a reference you can create sub reference with exactly the same content. Geraki TL 14:27, 8 August 2024 (UTC)Reply

Hi @Geraki, thanks for your feedback and for testing the feature! Yes you can indeed create sub-references with exactly the same content (see our example in WMDE Technical Wishes/Sub-referencing#Step by step (step 2, "This is what it looks like").
We gave another example in the same section (below the "Keep in mind" box) explaining how to re-use sub-references in wikitext. WMDE Technical Wishes/Sub-referencing#Re-using a sub-reference describes how to re-use them with Visual Editor (the same way how you would re-use any other reference). After re-using sub-references it looks like this [1]. Johannes Richter (WMDE) (talk) 11:07, 9 August 2024 (UTC)Reply
Hello @Johannes Richter (WMDE),
We have trouble using the sub-reference feature on ffwiki. Here is a sample article where it's used the types of error it displayed https://ff.wikipedia.org/wiki/Dentu%C9%97e,_Khorixas De-Invincible (talk) 12:27, 2 October 2024 (UTC)Reply
Hi @De-Invincible, thanks for your interest in our feature! The sub-referencing feature is still in development and can only be tested on beta-wiki. If you just wanted to re-use the identical reference in your ffwiki article, the wikitext should look like this [2]. See mw:Help:Cite#Multiple uses of the same footnote (for wikitext) or en:Help:Introduction to referencing with VisualEditor/4 (for VisualEditor) on how to re-use identical references. Johannes Richter (WMDE) (talk) 12:39, 2 October 2024 (UTC)Reply
Okay, Thank you for your help. De-Invincible (talk) 12:46, 2 October 2024 (UTC)Reply

Automated bot to convert to sub-references?

edit

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

Order

edit
Tracked in Phabricator:
Task T367749

Hi. Looks very nice. Though, I found a small inconsistency. The code

There is a great book about Mona Lisa<ref name="Kemp book">{{cite book |last=Kemp |first=Martin |author-link=Martin Kemp (art historian) |year=2006 |title=Leonardo da Vinci: The Marvelous Works of Nature and Man |publisher=[[Oxford University Press]] |location=Oxford |isbn=978-0-19-280725-0 |url={{google books|plainurl=y|id=Vdu0ynmoRc8C}} }}</ref> It has page 261.<ref extends="Kemp book" name="Kemp book 261">page 261</ref> It also has page 262.<ref extends="Kemp book">page 262</ref> To see page 261.<ref name="Kemp book 261"/>

works, and the code

It has page 261.<ref extends="Kemp book">page 261</ref> There is a great book about Mona Lisa<ref name="Kemp book">{{cite book |last=Kemp |first=Martin |author-link=Martin Kemp (art historian) |year=2006 |title=Leonardo da Vinci: The Marvelous Works of Nature and Man |publisher=[[Oxford University Press]] |location=Oxford |isbn=978-0-19-280725-0 |url={{google books|plainurl=y|id=Vdu0ynmoRc8C}} }}</ref> It also has page 262.<ref extends="Kemp book">page 262</ref>

works, while the code

To see page 261.<ref name="Kemp book 261"/> There is a great book about Mona Lisa<ref name="Kemp book">{{cite book |last=Kemp |first=Martin |author-link=Martin Kemp (art historian) |year=2006 |title=Leonardo da Vinci: The Marvelous Works of Nature and Man |publisher=[[Oxford University Press]] |location=Oxford |isbn=978-0-19-280725-0 |url={{google books|plainurl=y|id=Vdu0ynmoRc8C}} }}</ref> It has page 261.<ref extends="Kemp book" name="Kemp book 261">page 261</ref> It also has page 262.<ref extends="Kemp book">page 262</ref>

throws an unexpected and irrelevant error about beeing "Kemp book 261" defined multiple times with different texts, and another one about beeing "Kemp book 261" not defined at all. Both parts are reasonable by themselves, but not in the same time. Is there a purpose for such a behavior? Thank you. IKhitron (talk) 12:09, 12 August 2024 (UTC)Reply

Hi @IKhitron, thanks for testing the feature and leaving your feedback! We are aware of this bug and are going to fix it (phab:T367749). Johannes Richter (WMDE) (talk) 10:44, 13 August 2024 (UTC)Reply

RTL

edit

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 [3] 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 [4].
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

Bugs

edit

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

Unintended consequences

edit

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, enumlower-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

Numeration styles

edit

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

2 issues: template use, and keeping main ref inline

edit

I tried a test in the beta that used this wikitext:

New [[flash memory]]-based media implementations, such as [[solid-state drive]]s or [[USB flash drive]]s, can cause data erasure techniques to fail allowing [[remnant data]] to be recoverable.<ref name="m.wei">{{cite paper |title=Reliably Erasing Data From Flash-Based Solid State Drives |url=https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf |work=FAST '11: 9th USENIX Conference on File and Storage Technologies |date=2011-02-15 |access-date=2024-08-17 |author1=Michael Wei |author2=Laura M. Grupp |author3=Frederick E. Spada |author4=Steven Swanson |page=12 |quote=For sanitizing entire disks, built-in sanitize commands are effective when implemented correctly, and software techniques work most, but not all, of the time. We found that none of the available software techniques for sanitizing individual files were effective.}}</ref>

Then again, finding someon3 3lse's data can be entertaining!<ref extends="m.wei">{{cite paper |page=7337 |quote=Hax R Fun!}}</ref>

The 2nd "cite paper" template won't expand because it insists on having |title=. We should allow template users to keep using the syntax they expect, rather than forcing them to use unformatted text in subrefs. So the template may need to become more liberal in allowing partial citations.

Also, there seems to be no reason why the main ref can't be inline in the article and can't have its own page number and quote. Most pages I've edited in enwiki use inline citations; having a separate "references" section is unusual, unnecessary, and makes pages appear to be academic, not encyclopedic. The current design's need to "move" the main ref, and split out its overridden attributes, seems cruel, unusual, and unnecessary. Gnuish (talk) 13:11, 19 August 2024 (UTC)Reply

Hi @Gnuish, thanks for testing the feature and providing feedback!
  • Yes indeed communities might want to make some changes to allow more flexible use of templates for sub-referencing (or create new templates for sub-references which allow this flexibility). Without such templates we currently recommend using the sub-reference details as plain text.
Given that templates are community owned, it's up to local communities to change them, we don't want to interfere with that. We've talked about the feature and citation templates at the Wikimania and will contact communities with recommendations for templates and citation tools at a later point.
  • The main reference can be in line, it doesn't need to move. But there are some disadvantages if you don't move the main reference, e.g. that having the main reference inline also makes it appear as an actual reference. And it's also possible to keep details like page number etc. in the main reference, but that would result in the main reference showing a page number and the sub-reference showing another page number -> ReferencePreviews would show both numbers then. --Johannes Richter (WMDE) (talk) 13:48, 19 August 2024 (UTC)Reply
Have to agree that the main reference should be inline not in the reference section, as the problem with references in the reference section is that when section editing you cannot see the reference preview or edit it. It also makes the location of the reference difficult to find and edit. You should be able to see and edit the reference when editing a section. [See Community Wishlist/Wishes/Reference editing I have already raised.] Keith D (talk) 18:56, 19 August 2024 (UTC)Reply
If I remember correctly similar wishes have already been submitted to previous editions of the Community Wishlist Survey, unfortunately without it being picked up. I agree that this is already an issue with re-used reference which are defined in other sections of the article. We'll take a look if we can improve the situation while working on sub-referencing. Johannes Richter (WMDE) (talk) 07:25, 22 August 2024 (UTC)Reply
Thank you for the discussion. I mostly edit existing articles, rather than write new ones. Existing articles are (mostly) full of inline references. It is not a disadvantage that the main reference makes a footnote; that is exactly why it is there.
I don't exactly understand your mention of ReferencePreviews. Is this is the tooltip that appears from hovering over a ref number? There are no tooltips appearing over subrefs in articles, because subrefs don't exist yet. We can define what they would show. And we should define them to not show attributes from the main ref that were overridden in the subref (like a page number and a quote, in the example I posted).
Clearly there would need to be template development to make that happen. But did you really expect a subref facility to work well without cooperation from citation templates? < ref>Template:Cite ...< /ref>, is a hugely, hugely, hugely popular pattern in article space, at least in enwiki. Making subrefs work shouldn't require new work flows (like moving refs to a new section, or manually pulling individual attributes out into a subref). Computers are good at things like merging two lists of attributes with some overridden; we shouldn't require human editors to tediously do them.
Yes, occasional refs use plain text, sometimes intermixed with templates like Template:Isbn. If existing plain text refs that later got subreferenced show a suboptimal tooltip, that is not a major issue to me. Gnuish (talk) 20:47, 19 August 2024 (UTC)Reply
mw:ReferenceTooltips is the gadget enwiki (and a couple of other projects) are using as a default gadget, most projects are using mw:Referene Previews. Both create a pop-up that appears from hovering over a ref number (the screenshots shown in WMDE Technical Wishes/Sub-referencing#Problems for readers.)
While ReferenceTooltips can show the full content of sfn by having a pop-up on top of a pop-up, that's not possible in the mobile skin. Meanwhile sub-references will be properly displayed on all devices. Johannes Richter (WMDE) (talk) 07:36, 22 August 2024 (UTC)Reply
Templates are community-owned, so if enwiki or other projects want to use templates for sub-references, they can certainly do so. We've intentionally created sub-references in a way that they are working with all kinds of different details and also templates if communities choose to do so. Our examples simple don't show templates, because we wanted to explain the solution as simple as possible. I've already seen someone experimenting with a demo template they created [5] and knowing the communities I'm sure we'll see more of that.
The idea of just overriding stuff that's within templates sounds simple, but not if you consider how many different citation templates enwiki alone uses and that we are providing a feature to hundreds of Wikimedia projects and many of them have developed their own templates over the years (especially if you look at right-to-left languages). Templates are a great tool of customization for local projects, but that also makes it really hard for software features intended to serve all projects. Johannes Richter (WMDE) (talk) 07:42, 22 August 2024 (UTC)Reply
This looks like something that would make me avoid using sub-referencing: the fact that there's no easy way to treat the first mention of a reference (with some page number) the same way other mentions are treated (with their own page numbers). It's a major design flaw, IMO. The solution would be to have the ref's instance data travel with its invocations (<ref name="" pages="" othersubreftypes="" />). It'd also help with translations: now, every <ref name="" extends="">Страницы 2 - 5</ref> needs to be translated manually. ponor (talk) 14:58, 21 August 2024 (UTC)Reply
@Ponor thanks for your feedback. If I understand you correctly (I'm not a 100% sure) the issue you are mentioning is basically the same with the current ref name approach, where the first mention is also different to all re-uses?
We've explained our syntax choice in WMDE Technical Wishes/Sub-referencing#Why did you choose this wikitext syntax? and I've provided more details below in #Simplicity. Your approach appears simple at first, but has some other issues. That's why decided to go for this approach, which is similar to they way people are already used to with <ref name> --Johannes Richter (WMDE) (talk) 07:56, 22 August 2024 (UTC)Reply
@Gnuish: The feature needs its own template. Check out https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Medieval_Arabic_female_poets&oldid=629222 The template there is just a demo and it's awful, but it's meant to give an idea. Regards, Rjjiii (talk) 05:12, 22 August 2024 (UTC)Reply

Simplicity

edit

This is definitely a huge improvement, but I wonder why this can't be even simpler. {{rp}} templates are still much easier to use than this, you just insert the template and done, while the new approach requires several steps and more complex syntax. For example, it would be simpler to define page numbers like this: <ref name="Miller" extends="page 20"/>. Also, it would be ideal if the software could detect and group duplicate page numbers automatically, so that there is no need to give the sub-reference a name. Jens Lallensack (talk) 13:16, 19 August 2024 (UTC)Reply

I'm thinking about somewhat similar syntax (pages in an attribute).
I think it would be useful to define a first reference and add an extensions attribute with VE. Something like this:
  1. Generate a reference (e.g., from a URL/DOI/ISBN).
  2. Mark the reference as extendable (activate "extension" field).
  3. Add text to reference a specific page (or specific time in a video/audio file).
When saving (applying changes) in VE, this might be turned into:
<ref name=":1" extension="page 20">{{Cite web |title=UCLA Slang 2 | url=https://example.com}}</ref>
And then reuse it like so:
<ref extends=":1" extension="page 22"/>
Or reuse it like so:
<ref extends=":1">page 22</ref>
This might make sub-referencing easier than using the sfn template and similar methods because I don't have to define the reference first and then use it (I can define and use it in one go).
So, sub-referencing functionality must allow that the first reference created is both extendable and includes specific pages. Otherwise, I fear this might not be picked up by communities due to too much friction and too little gain. And I would love this to get picked up :) Nux (talk) 14:25, 19 August 2024 (UTC)Reply
Hi @Jens Lallensack and @Nux, thanks for your feedback!
  • Yes {{rp}} is indeed a simpler wikitext solution for use cases like different page numbers. But it has some other limitations, e.g. those details not being included in Reference Tooltips / ReferencePreviews and the template not properly working in Visual Editor (yes it's possible to insert / edit the template in VE, but not via the citation button).
  • We've tried to explain our syntax in WMDE Technical Wishes/Sub-referencing#Why did you choose this wikitext syntax?. In a nutshell: The approach you're suggesting only works for page numbers (or anything else that get's a defined parameter), while sub-referencing aims to allow re-uses of references with all different kinds of details.
In addition this approach can cause issues with templates and doesn't allow to re-use sub-references (the difference between non-reused [6] and re-used [7] might not seem that important at first glance, but some long lists use the same source (with different details) dozens of times, then re-using sub-references to organize the reference section is of great value for readers.
Johannes Richter (WMDE) (talk) 14:33, 19 August 2024 (UTC)Reply
Thanks. So the problem with having subreferences details within the <ref> tag, which would be so much easier, are problems with templates and not being able to re-use sub-references. But are those template problems really unsolvable, or is it just that we would have to update numerous templates? I personally think that it is better to invest the work to arrive at a solution that makes editing Wikipedia a lot easier. For the second point (re-use of sub-references), I do not quite understand why an automatic solution will not do the trick. The software could group sub-references whenever strings entered in the "extends" fields are identical. We would then have to repeat these strings all over again in an article, but we won't have to define and repeat subreference-names. I understand that this automatic grouping might be tedious when the user wants to enter longer text, but those usecases are rare (and other approaches are still available for that); in almost all cases it will just be page numbers. Jens Lallensack (talk) 15:22, 19 August 2024 (UTC)Reply
If we just look at one single project like enwiki it's surely possible to solve template issues, but given that we're providing a feature for hundreds of Wikipedia language versions and their sister projects and that all of those projects don't just use the same templates, but have created different ones (or variations of initially similar ones) over the years, our approach seems more feasible – especially considering how many kinds of different details (other than page numbers) there are which people might want to use.
Regarding auto-merging of identical references: That's something we've considered as well (because this feature is part of some larger research on how to improve re-using references). There are two main issues with that: This idea wouldn't be consistent with user expectations. When I'm using ref name (or in the future ref extends as well), I expect some kind of re-use. When I don't use any reference attribute, I'm expecting my reference to appear as a single citation in the reference list. And some users might intentionally want to separate two identical references for some reason and not make them appear as re-used reference. Johannes Richter (WMDE) (talk) 06:57, 22 August 2024 (UTC)Reply
@Johannes Richter (WMDE) thanks. I think it would be possible to do what Jens said if a different, separate name of an attribute would be used as an extension. To address what you said:
  • You can use this do define time: `extension="1 min 53 sec."` (or extra="1 min 53 sec." or subref="1 min 53 sec.").
  • Using an attribute allows you to have a clear separation when you define a first ref with pages. Easier then having a separate ref definition in references. I think it would not be possible to make an edit like that in VE alone.
  • Finally when saving the page VE could still detect duplicates and add names (like Jens suggested). E.g. change: `ref extends=":1" extension="page 22"` to `ref name=":2" extends=":1" extension="page 22"` (so generate a name) and any other usages to `ref name=":2"`.
To be clear I'm not saying subrefs should be displayed as rp template, I'm just saying you could support both an attribute and ref tag content as an extension of the original reference (and that would open up some new possibilities) Nux (talk) 15:35, 19 August 2024 (UTC)Reply
Interesting idea. But wouldn't that increase the complexity in Wikitext a lot, if we added a third attribute name? And another issue: Our current approach allows for templates to be used for sub-references if communities want to do that, which would be much more difficult if the content doesn't appear between ref-tags but within a ref-tag: Something like <ref name":2" extends=":1" extension="{{subref-template|Chapter=12|Page=107|Quote=ABC}}" /> would be incredible hard to achieve if I'm not mistaken, due to the way pages are rendered. While <ref name":2" extends=":1">{{subref-template|Chapter=12|Page=107|Quote=ABC}}</ref> pretty much just works the way we are already used to with citation templates. Johannes Richter (WMDE) (talk) 07:11, 22 August 2024 (UTC)Reply
@Johannes Richter (WMDE) I don't see any other way to be able to define a main reference in text. Seb-ref requires that the reference is defined without pages (extension doesn't replace page argument of the template) and per Wikipedia rules I cannot add a book reference without pages. So there seem to be no good way define the main ref in text (you have to define it in references tag and so edit the references section separately). This makes sub-refs as complicated as sfn already is (in terms of initial procedure to make it work at least). And also, if I'm reading Jens proposal correctly, he considered an attribute simpler to use then content of the tag. So this is kind of simpler: <ref extends="Miller" extension="page 20"/>.

As for the templates for sub-refs... personally I wouldn't want any templates in there. I understand some might want that, but I think templates would only complicate things with very little gain... Having said that, I'm guessing it might be possible to allow both of the syntaxes (both attribute and tag content interchangeably) and so if someone would really want a template he could use a template (with added complexity of defining ref in references section). Nux (talk) 08:22, 22 August 2024 (UTC)Reply
Ahh maybe I misunderstood what you initially said. You goal is to define a main reference in line but without a footnote marker showing – basically putting something like <ref name="MainRef">ABC></ref><ref extends="MainRef">ABC</ref> in the article text but with only the sub-ref showing, so that you don't need to define the main reference in the reference section? Johannes Richter (WMDE) (talk) 09:08, 22 August 2024 (UTC)Reply
Hm... No? I'm not sure what you mean, but I think that's not what I mean 🙃... My goal would be to create two refs with pages using two ref tags. So like this one:
https://en.m.wikipedia.beta.wmflabs.org/w/index.php?diff=628938&oldid=628036&title=Hella
...but without using <references>. Nux (talk) 19:27, 22 August 2024 (UTC)Reply
Sorry I think I got lost somehow between the different comments, you even demonstrated how you imagine the wikitext to look like in your first comment.
We've decided against such a syntax due to the reasons mentioned above, but we are desiring a VisualEditor workflow which feels similar, allowing you to create main- and sub-reference in one go, probably without even noticing that these are two steps in wikitext. We are currently doing user tests on that for the next iterations of our VE prototype. Johannes Richter (WMDE) (talk) 15:09, 26 August 2024 (UTC)Reply
I hope that the old {{rp}} will always remain available.A ntv (talk) 16:17, 19 August 2024 (UTC)Reply
Hi @A ntv, most projects have adopted policies like en:WP:CITEVAR. As long as communities don't change their policies (but that's up to them and nothing we'll be involved in), you can continue to use your preferred way of referencing. Johannes Richter (WMDE) (talk) 06:59, 22 August 2024 (UTC)Reply

Duplicate subrefs with VE

edit

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

Columns?

edit

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

Reusing the main reference

edit

Is it possible to use both subreferences (where you know the page number), and in some cases call the main reference itself (where the page number is not known - useful eg when migrating an existing article or adding subreferences on an article that does not currently have them)? ProcrastinatingReader (talk) 18:28, 19 August 2024 (UTC)Reply

Try to move the main reference from the references section to the proper place in the text. IKhitron (talk) 20:45, 19 August 2024 (UTC)Reply
Hi @ProcrastinatingReader, you can do it the way @IKhitron suggested (although I wouldn't recommend that, because this could currently cause bugs in some edge cases). More simpler: You can just use <ref name="Name of the main reference" /> in Wikitext or use the re-use button in the Visual Editor citation dialog to re-use the main reference in case you don't know the page number (example). Johannes Richter (WMDE) (talk) 06:40, 22 August 2024 (UTC)Reply
I see. It seems contrintuitive, so I believe you should emphasize this point in the instructions. IKhitron (talk) 09:29, 22 August 2024 (UTC)Reply
Thanks for the suggestion! We'll make some amendments to the page this week, including some best practices or more advanced examples, which will include something like this as well. Johannes Richter (WMDE) (talk) 14:01, 26 August 2024 (UTC)Reply

I think this is a similar observation so I'll put it here. It took me a few moments, and a test, to realise I had to find a reference without a page number to be the main reference. If there was no potential main reference, I assume I'd have to create one somewhere. --Northernhenge (talk) 15:49, 27 August 2024 (UTC)Reply

Hi @Northernhenge, if you want to use sub-referencing with existing citations, you'll likely need to follow the steps we've outlined in WMDE Technical Wishes/Sub-referencing#keepinmind to convert an existing reference into a main reference and then use sub-referencing. Johannes Richter (WMDE) (talk) 16:00, 27 August 2024 (UTC)Reply
Just saw that you used the VisualEditor for testing: We are still working on some VE workflows, converting an existing reference to main and sub-reference in VE is one of them. Johannes Richter (WMDE) (talk) 16:12, 27 August 2024 (UTC)Reply
Thanks for the quick response. Yes, I went into VisualEditor but came straight out again to do the edit! It was all very straightforward to use. -—Northernhenge (talk) 16:16, 27 August 2024 (UTC)Reply

Chapters

edit

This is great for citing chapters within a book without having to use convoluted syntax (e.g., harvnb for the book and cite book for the chapter). Great stuff!


However, for page numbers, I prefer rp, which doesn't generate additional fns. In that spirit, it would be nice to give rp refname= so you don't have to have 2 elements. And url= to take you to the page. Lfstevens (talk) 02:30, 20 August 2024 (UTC)Reply

Hi @Lfstevens, thanks for your feedback! I agree that there might be use cases where current template-based solutions appear to be simpler (especially if you're already used to them). We've intentionally designed sub-referencing to work with all kinds of different details, I'm glad you like the feature for citing different chapters of a book! Johannes Richter (WMDE) (talk) 06:34, 22 August 2024 (UTC)Reply

Verbose

edit

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 visual options in VE

edit

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

Feedback

edit
  1. Finding how to insert sub-referencing is not as intuitive. I would expect to be able to select a citation and find a button that says "extend this reference". Instead, when editing an existing regular citation I am offered possibility to "convert to sub-reference" which makes very little sense and misleads me.
  2. Once I found correct way to add a sub reference (by inserting a new citation) I still had to search down all the citations until I found the correct reference. For short articles this is acceptable, for longer ones it can be tedious. Scanning and defauling the reference to the immediate left would be an enhancement.
  3. When I copy a sub-reference from one article to another article, I would expect it to copy the citation as well. It does not, it only copies the name of the named reference. With generic named references like ":0", ":1" it is likely this error will fail silently. I find named references incredibly broken/unusable (for both regular/sub references) and it hampers the experience here as well. See Community Wishlist/Wishes/Improved named references for further feedback.
  4. Sub-reference is good name, but the interface only shows how to "extend", creating confusion for new users
  5. Editing sub-reference should say "Extend a different reference" instead of the main "Replace citation" interface/language of a reference
  6. Editing sub-references inside reference section is still not possible.
  7. Make name parameter inside references and sub-reference editable. Currently it's impossible to know how to change it while using VE.
  8. In short, I would absolutely love to use this and will stop using en:Template:Rp and also use this to extend different chapters of common book. It is clear/easier to edit than sourced foot notes

Shushugah (talk) 22:43, 20 August 2024 (UTC)Reply

Thanks for you detailed feedback @Shushugah!
  • We are still working on many sub-referencing workflows for Visual Editor. What you've mentioned in 1) is something we are already considering, because user testing shows how important workflows other than the citation button are.
  • The (already existing) issue with VE auto-generating meaningless reference names is something we are aware of as well. We cannot make a promise on that part, but we might be able to add a promt for VE users to give the reference a meaningful name. By the way: Did you know you can use the search bar to find a reference, even if the name is just a number (example)?
  • Thanks for your feedback about copying a sub-reference to another article in VE, that's also something we'll look at.
  • 4 & 5 will definitely be changed, that's just preliminary wording for the prototype.
  • We are aware of the issue with editing sub-references directly in the reference list, that's also something we want to look at.
Johannes Richter (WMDE) (talk) 15:13, 21 August 2024 (UTC)Reply

VE: moving main reference inside references tag

edit

While adding a new reference using VE and then subreferences, I get a situation where a main reference is paired with a first subreference, e.g. [1][1.1]. There should be a way to 'hide' the main reference inside references tags (and maybe it should be a default option as it would be just a citation overkill with more references like that). Wostr (talk) 12:42, 21 August 2024 (UTC)Reply

Hi @Wostr, thanks for testing the feature and leaving your feedback. This is something we are aware of and part of the userworkflows we are still going to improve. In the final version VE should "move" the first reference as a main reference to the references section so that it doesn't create a footnote marker and only the sub-reference stays in the article section. Johannes Richter (WMDE) (talk) 06:06, 22 August 2024 (UTC)Reply

Needs to work with inline named refs and {{reflist}}

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

I'll be grateful

edit

I'll be really greatful for getting this in Visual Editor. It will significantly shorten and clarify the reference list of the article. Kaupunkilehmus (talk) 15:25, 21 August 2024 (UTC)Reply

Thanks for your feedback! Johannes Richter (WMDE) (talk) 06:06, 22 August 2024 (UTC)Reply

Wherever?

edit

The term wherever bothers me: Elaborate please. Do we try and imply sub-references are applicable to captions, navbox, infobox, or even nest inside ==References==? IMHO, other language translators seems to try and convey the meaning but not one target. — Omotecho (talk) 03:28, 22 August 2024 (UTC)Reply

Hi @Omotecho, it should be possible to use sub-references anywhere in the article, just like you can do with regular and re-used references. If it's confusing, we could probably just shorten the sentence "Create more sub-references wherever you want to cite the source with different details in the article" and replace it with "Create more sub-references to cite the source with different details in the article"? Johannes Richter (WMDE) (talk) 06:09, 22 August 2024 (UTC)Reply
@Johannes Richter (WMDE), yes, that is great, and my concern is maybe through a learning users' eyeglasses in two parts:
  1. Could we link to basics of referencing/giving footnotes anyhow, maybe at section == See also ==? That way, "anywhere" sounds more realistic IMHO;
  2. Is the goal of Feedback Wanted this cycle set to measure feasibility how/why sub/main-reference is the best for wikipedias?
For #1, I am sure local wikis have their own way to explain things, and on meta, we are not (at some given time) caretakers of budding editors. Or, local "help" pages depends largely on meta, that is why translators are particular about minor details. q;
My feedback: more basic than what can contribute to your call.
As somebody has already pointed out above, you are facing the dilemma of choosing among referencing styles/formats.
Unmatching reference styles among language wikis trigger henpecking.
Personally, I have worried over ten years which footnote style I am safe to use when editing existing articles on jawp: henpecking starts when you apply harvnb or Rp or full citation, and ignore the style applied throughout the older revisions, or if you expand an article with translation from other languages or inter-wiki pages.
Ignoring footnotes signals copyvio for translated pages
I have been checking translated articles on jawp, mainly for checking copyvio without "translated from &odlid notes", which I find by checking articles without footnotes. It is that serious as there are users who drop/delete ref tags/references altogether when translating, afraid of being RfCed that their referencing style is irresponsible. House keeping and cutting open the jumble of harvid-harvnb/Rps/full citation and bare urls in a single article tends to be the worst nightmare to keep the encyclopedia-quality.
Referencing is not the most respected pillar among the five locally
If I may go off the track, I should admit jawp has not overcome the superstition that "translating non-ja article is the speediest way to champion edit count, and hey, there are handy machine translation apps or sites!". Contents Translation 2 (CX2) is disabled on jawp, but still referencing and translation are water to oil, and we need a good textbook-help page backed with meta wisdom. Omotecho (talk) 07:46, 22 August 2024 (UTC)Reply
Hi @Omotecho, we've linked to basics of referencing in the section WMDE Technical Wishes/Sub-referencing#The problem we are solving – most of the wikilinks in that section point to mw:Help:Cite or similar pages, is that what you mean?
We've already done extensive user testing and feedback rounds over the years (see WMDE Technical Wishes/Sub-referencing/History), but in past months/years usually with smaller groups of editors. Our current goal is to a) announce to all local communities that this feature is coming in a couple of months and b) use the opportunity (while we are reaching out to more people than ever using Mass Messages, mailing lists and CentralNotice banners) to also collect feedback from a broader audience for further improvements on the current prototype (especially the Visual Editor solution, which will see major improvements in the next weeks/months).
We are aware of local help pages for referencing and will try to assist communities updating those. But that should happen at a later point, closer to the features actual deployment and not now when details of the feature will still change. We'll make further announcements in the next couple of months, so communities can prepare their help pages in time. Currently as long as users understand how the feature is going to work, how they can test the prototype at beta-wiki and how they can give feedback, I think that's all we can ask :)
Regarding referencing styles: That's one of the issues we've considered when creating sub-referencing and one reasons why we chose an approach closely related to the existing <ref name> concept, knowing that all citation templates have the disadvantage, that different communities use different templates (e.g. I'm a dewiki admin in my volunteer capacity and we don't use something like harvnb or rp at all). Of course communities can continue to use their preferred templates, but if you translate an article using sub-referencing, there should be no issue just using the same sub-reference in your translation. If that can help projects which have issues with referencing, I would be very happy about that. Johannes Richter (WMDE) (talk) 08:15, 22 August 2024 (UTC)Reply

Reference previews and tooltips

edit
 

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

Extends is an awful name

edit

I will definitely be checking this out and testing it. But allow me to say right off the bat that the term extends is a poor choice of name for this attribute. It sounds so oriented towards the software architect, as if it came out of a page about OOP inheritance, and so utterly unrelated to how a user might think.

Consciously or unconsciously, you have already provided the natural name for it, where you explain right in the beginning, in the Nutshell section:

To cite a source more than once with different details, you need a main reference and a sub-reference.
  • The main reference contains the main bibliographic information.

And there you have it: <ref main="Miller">Page 23.</ref> : a completely natural term, and one which you are already using. The other terms that come to mind are base and root, but main seems much the best of the three. Cheers, Mathglot (talk) 19:00, 22 August 2024 (UTC)Reply

I like "Main" Lfstevens (talk) 19:53, 22 August 2024 (UTC)Reply

Just for the record, some other terms that came to mind just afterward, include: primary, parent, anchor, and core, but I still like main best. Mathglot (talk) 19:57, 22 August 2024 (UTC)Reply

Support. When I localized the sub-references on beta for our wiki last week, I used "main", it seems me much better. IKhitron (talk) 20:11, 22 August 2024 (UTC)Reply
Hi @IKhitron, apologies, I forgot to ping you in my previous reply. Thanks for the pointer to your adaption on he-betawiki! -- Johanna Strodt (WMDE) (talk) 09:05, 23 August 2024 (UTC)Reply

(Main) Reference and (Sub)-Reference are intuitive as a pair for both the code and citation templates?. What would the verb be? Extend, annotate, specify? Shushugah (talk) 23:01, 22 August 2024 (UTC)Reply

@Mathglot, @Lfstevens, @Shushugah: Thanks a lot for your comments! Yes, we have received mixed feedback on extends, which is why there is no final decision on the attribute name yet. In user testing, we recently tested different options – including main – and the feedback was again very mixed, with no clear overall preference for one particular name. I will take your feedback to the team. And of course, if anyone wants to add their thoughts on this, please do so. -- Wishing you a good weekend, Johanna Strodt (WMDE) (talk) 08:49, 23 August 2024 (UTC)Reply
I am also adding my colleague Johannes' reply on the English Wikipedia's village pump here:
"We’ve done several consultations with the global community and a lot of user testing in past years where we asked for feedback and ideas on the attribute name. One takeaway is that the name is less important for many users than we initially thought, as long as they can remember it. And our user tests showed a surprisingly large number of Wikitext users switching to VE in order to use the citation dialog (for referencing in general, not just for sub-referencing) – if you do that, you don’t need to deal with the attribute name at all. We didn’t see any major issues with “extends” for people exclusively using Wikitext in our user tests. But so far there is no final decision on the attribute name, so if you have any ideas let us know (we’ll make a final decision soon)."
-- Again, happy weekend, Johanna Strodt (WMDE) (talk) 11:12, 23 August 2024 (UTC)Reply
Yes, being able to remember it is probably the most important thing for me. "Extends" made complete sense to me (though I have done software in the past). "Main" is the kind of word I could easily forget. --Northernhenge (talk) 15:44, 27 August 2024 (UTC)Reply
As for myself, "main" makes sense, and "extends" is the kind of word I could easily forget. Batrachoseps (talk) 02:36, 30 August 2024 (UTC)Reply
I think the issue here is that "extends" is unclear about what information needs to go there, whereas "main" is unclear about what the information is doing.
I lean towards "main" myself, because it's more helpful to a new user, but something like subcite_of could be clearer than either. —Closed Limelike Curves (talk) 23:18, 18 December 2024 (UTC)Reply
Perhaps generating a specific "instance" of the main reference (as in "an occurrence"). Or "subcite", because we are citing a piece of the original reference as opposed to citing something bigger to create a full reference.
  • I think the problem with the term "extends" is that it implies the main reference is having its scope broadened, when in fact the subreference is narrowing its scope by (at least usually) referring to specific page numbers.
And perhaps "main reference" could be "parent reference", "full reference", or "independent reference". GreekApple123 (talk) 16:38, 31 August 2024 (UTC)Reply

Override, don't show details twice

edit

In your step four in the Keep in mind, you say:

4. Move the details of the main reference (page numbers etc.) into the sub-reference. Make sure they no longer remain in the main reference, otherwise those details will be shown twice.

Please allow duplication of the same item in the subref, and don't show them twice, but override the main one with the details from the sub-ref.

The most obvious use case that springs immediately to mind is {{cite journal}}-type references, where you will have a journal article which occupies |pages=67–102 of that issue of the journal, but where the subrefs verify assertions from, say, pages 71–72, page 69, and pages 94–96. What we want here, is |pages=67–102 in the main ref, and three subrefs mentioning only the page or range applicable to that one citation, where the full page range of the article should not be repeated, and can be found in the main link, just like all the other bibliographic info can.

A related use case would be sources that use subpart names and section numbering, like, say, the French legal code at Légifrance, where you have the criminal code, with book one, title one, chapter one General Principles, which consists of code items 111-1 to 111-5, and then you have the individual code items, like § 111-3 (the nulla poena sine lege principle). (This obviously hints at the possibility of cascading subrefs, but that's another topic.)

A different use case might be for multiple editions. Articles not infrequently end up with citations to the same item from different years, either different editions or reprints. At en-wiki, this can currently be handled, sort of, by the |orig-date= param of the cite suite of templates, but it is awkward, and involves stuffing a date, possibly a publisher and location into a date field, and if the original edition is cited as well, you still need to have two references; a much more natural way of linkage would be via a subref pointing to the earlier edition as the main ref, but the subref should not show both edition values, it should override the edition value (if any) from the main ref, and only show the subref edition. Less frequently, the publisher or location might change, or the isbn, or the name of the series or collection, and the oclc number will definitely change, but the same should apply in any of those: the subref details should override any value given in the main ref.

Another case might be for translations, or for print vs. online versions of the same resource, and there may be others. For all of these, it would be annoying to display duplicated details from the main ref in the subref that instead should be overridden, but there should be no prohibition against including them in the main ref. There is already precedent for this, in the way in which en-wiki's en:Template:Citec operates, with values in the Citec overriding the values in the main ref. Subref should operate similarly (and should ultimately replace Citec as a more native way of handling it). Mathglot (talk) 20:29, 22 August 2024 (UTC)Reply

I like the idea of any matching parameters inside sub-reference overriding the reference -- strictly in presentation mode. We should be careful about not literally removing parameters in main reference. The case where a parent reference has a wide range of pages, but sub-reference has exact page is one use case. Shushugah (talk) 23:05, 22 August 2024 (UTC)Reply
@Mathglot Thanks a lot for your suggestion and for taking the time to explain it here with much detail; it is appreciated. Our team has discussed this idea before, and it is quite complex, for some reasons, including:
  • Which part of the main reference would be overridden might not be obvious to users while editing, even if it were defined somewhere. Plus, integrating this is not simple.
  • If I understood your proposal correctly, it would also create some inconsistencies: If the main reference in the reference list is shown with the details, that would be inconsistent for readers – why are some details in the sub-references and others aren’t? If the main reference in the reference list shows no details, it would be inconsistent and probably confusing for editors to see the details in the wikitext.
In our approach, you have a main reference and the details are only in the sub-references:
1. Journal name, location, edition etc.
1.1 pp. 67–102
1.2 pp. 71–72
1.3 p. 69
1.4 pp. 94–96
Apart from having an alternative proposal, I would like to understand better where specifically you have problems with our proposed solution. Can I ask you to elaborate a bit more? That would be very helpful. — Thanks again, and I wish you a good weekend, Johanna Strodt (WMDE) (talk) 10:58, 23 August 2024 (UTC)Reply

Bug adding any template into any sub-reference on Visual Editor

edit

Has anyone else tried to add a template into a sub-reference with the Visual Editor? I tried on Firefox, Chrome, and Edge and had the same result for each. Windows 10 for all. Signed in and signed out. To reproduce:

  1. Edit a page with the Visual Editor.
  2. Click the quote mark to add a citation.
  3. Select "Extends".
  4. Select a main reference.
  5. In the box, type "{{" or select "insert→template".
  6. The "Insert a template" box appears greyed out and behind the "Extend a reference" box.

If you zoom out far enough, you can still use the faded "Insert a template" box, but this seems not how it's meant to be. Rjjiii (talk) 01:58, 23 August 2024 (UTC)Reply

Thanks, Rjjiii. I have created a Phabricator ticket for this issue: phab:T373186. -- Best, Johanna Strodt (WMDE) (talk) 11:27, 23 August 2024 (UTC)Reply
Thanks! Rjjiii (talk) 13:50, 23 August 2024 (UTC)Reply

Several things

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 [8], 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

Bug when reusing sub-references in the visual editor

The visual editor will show the main citation for a subreference, but not if it is being re-used from a named reference. The main reference seems not to display in Visual Editor any time it is being reused. So "<ref extends="Tahera Qutbuddin" name="Tahera Qutbuddin, p. 867">p. 867</ref>" works as expected, but when reused "<ref name="Tahera Qutbuddin, p. 867" />" does not.

To reproduce:

  1. Go to a page with named and reused sub-references like this one: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Medieval_Arabic_female_poets&oldid=626822
  2. Click "Edit" to open in the Visual Editor
  3. Click the first "[5.1]"
  4. You should see the main reference and the sub-reference below it. (Works as expected for me.)
  5. Click the second "[5.1]"
  6. You will see only the sub-reference. The main reference is not displayed.

Tested on Chrome, Firefox, and Edge. Windows 10. Logged in and logged out. Rjjiii (talk) 20:30, 24 August 2024 (UTC)Reply

Hi @Rjjiii, thanks for pointing this out! That's a known bug (phab:T369801) and we'll of course fix it, once we've completed some necessary code cleanup for that task. Johannes Richter (WMDE) (talk) 05:31, 27 August 2024 (UTC)Reply

The colour of decimal point in two-part references

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

Short form with template?

Would it be possible to have a templated version of the inline placeholder that is even shorter?

I make extensive use of SFN in my writing as I find it makes future editing dramatically easier due to the limited space it takes up in the source and it being much easier to type without blowing the tags and leaving an unbounded ref.

So perhaps a "SR" (sub-ref) template? Something like SR|refname|pagenum? Maury Markowitz (talk) 13:54, 27 August 2024 (UTC)Reply

Hi @Maury Markowitz, thanks for your idea! Given that templates are community-owned and that it's also up to local communities to decide which citation styles they want, it will be up to them to decide about this. Above some user already linked a test with a demo subref template they created. Being also a volunteer I could very much imagine using such sub-reference templates. Johannes Richter (WMDE) (talk) 14:28, 27 August 2024 (UTC)Reply
@Maury Markowitz: There are several places you may want to bring this up on the English wikipedia. The {{r}} talk page has previously discussed trying to implement a feature like sub-referencing. That template already accepts the syntax, {{r|refname|p=pagenum}}. It currently generates superscript page numbers, like this:[1]: 23 but could be updated to make sub-references. At Help talk:Citation Style 1, an editor floated a similar way of using templates to what you propose. The demo template mentioned above works inside ref tags, more like {{harvnb}} than {{sfn}}. (I am MercyMercy on the beta wiki, because when making an account you get this ominous message saying that no data on the beta wiki is safe?) If you want to try porting {{r}} over to the beta wiki to see how it handles sub-references, be sure to port over its 4 subpage templates. The wikitext in the template's code is pretty complex because it supports calling a bunch of references at one time, quotations in mouse-over tooltips, and some other rarely used stuff. A final note, any template that is using "#tag:ref" will create a reference not visible in the Visual Editor; this is currently an accepted downside to using sfn. Hope that helps, Rjjiii (talk) 05:03, 29 August 2024 (UTC)Reply

Machine-readable data

edit

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 [9] testing a demo template for sub-references they created on betawiki [10] 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 [11], 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

Good luck with that!

edit

Seems like just another Wikipedia foggy edit cloud that no sane human being can understand. G41rn8 (talk) 05:49, 30 August 2024 (UTC)Reply

Hi G41rn8, would you like to elaborate what you don't like/understand about the feature? Our approach for both wikitext and VisualEditor is based on existing ways of referencing and we don't see major issues in user testing as well as community feedback – even people who prefer other ways of referencing (e.g. sfn) seem to have no problem understanding how to use sub-referencing. Johannes Richter (WMDE) (talk) 05:42, 2 September 2024 (UTC)Reply
I found the syntax easy and organized, "details" is the key word in the sub-reference. The problem will be if someone deletes the main reference. Elilopes (talk) 16:25, 17 December 2024 (UTC)Reply
Thanks for your feedback! We'll show a warning if user's delete the main reference, similar to what already happens if users delete a re-used reference. Johannes Richter (WMDE) (talk) 17:15, 17 December 2024 (UTC)Reply

Deleting a reference that is being re-used

edit

Regarding the concern, We have yet to work on what happens when you delete a reference that is being re-used; the ideal solution should be to warn the editor and disallow deletion of a main/parent reference if the editor does not also delete all the sub/dependent references. No one wants to clean the mess left by other editors. - hako9 (talk) 18:36, 10 September 2024 (UTC)Reply

Hi @Hako9, thanks for your suggestion! That's indeed something we are considering, but we're still figuring out how the warnings should look like / at which point of the edit process they should appear. We could probably use Edit check or something similar for VisualEditor, but need to think about Wikitext as well (currently if you mess up any references (not just main- and sub-references) in Wikitext, there are no warnings and only after saving warnings like Cite error references no text are shown and the page appears in subcategories of Category:Pages with citation errors). Johannes Richter (WMDE) (talk) 13:10, 16 September 2024 (UTC)Reply

Wishlist: Make subreferencing work with inline refs and reflist

edit

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 [12]. --Johannes Richter (WMDE) (talk) 07:51, 23 October 2024 (UTC)Reply

Any updates?

edit

Hello, just a quick question. According to the "Recent changes and next steps" section: We are reaching out to potential pilot wikis and are planning to deploy the sub-referencing feature on those wikis in October. Is this feature deployed already on any wiki? How is the progress? Cheers, tufor (talk) 21:27, 28 October 2024 (UTC)Reply

Hi @Tufor, thanks for bringing this up. Unfortunately our work on sub-referencing is delayed. We are currently exploring changes to the sub-referencing feature based on the community feedback we got (both on this talk page as well as on many local village pumps – huge thank you to everyone who shared their perspective). We will reach out to communities soon to get more feedback on some proposed changes.
I've updated the outdated project page section [13]. Johannes Richter (WMDE) (talk) 13:06, 29 October 2024 (UTC)Reply

Request for feedback

edit

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 &quot; 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 &quot; in wikitext. Other special characters which might need to be handled similarly when used with details="..." are < and >.

Questions on sub-referencing

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

Questions on {{reflist}}

edit

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
Return to "WMDE Technical Wishes/Sub-referencing" page.