Please share your thoughts on the proposed solutions. Feel free to discuss in your native language, we want to make sure that everyone can participate. We will add machine translations to non-English comments in order to make it easier for everyone to follow the discussion.

We are happy about suggestions for improving certain details of the proposed solutions. Any other feedback and alternative proposals are also welcome – even though it’s out of scope for us, it might still be relevant for future work on this topic. As indicated in our proposal, we can only implement the solutions if there’s clear consensus by the global community.

Please support us interpreting consensus by clearly indicating your opinion (e.g. by using polling templates like Support Support/Neutral Neutral/Oppose Oppose). We are aware of en:WP:NOTVOTE, but given that we are facilitating this discussion with users from different wikis, potentially commenting in their native language, clearly indicating your position helps us avoid misunderstandings.

Thank you for participating! --Johannes Richter (WMDE) (talk) 10:26, 19 March 2026 (UTC)Reply

I'm not exactly sure how this is a RFC, or what anyone would be supporting not opposing. Could you clarify?
Separately I'm slightly worried by this statement:
Copying a named reference from a different article will keep its name preserved. Handling renaming of references is considered a separate problem.
What happens if there is a conflict between reference names? Copying a reference into a new article and leaving it as a large red error message wouldn't be helpful. Does the current solution have a way of avoiding reference name conflicts, and how does it go about resolving them? -- LCU ActivelyDisinterested «@» °∆t° 12:45, 19 March 2026 (UTC)Reply
We are proposing different solutions. We will implement all of them if there's consensus among community members to do so, but we could also implement just some of the solutions if that's what the community asks us to do. And if it turns out you dislike all of the proposals, we won't make changes to automatic reference names and consider working on other improvements to referencing.
When copying and pasting a named reference to another article in VisualEditor, VE automatically adds a number to the reference name if there's already an existing reference with the same name. That's how we would handle it as well. We just wanted to make it clear, that the proposal doesn't allow changing such a reference name in VE. Some users copy+paste references from one article to another in order to use them as a "template" (-> keep the formatting but change the content). If the pasted reference already has a name, we wouldn't change it when the user changes the reference content (e.g. author, title...). Johannes Richter (WMDE) (talk) 13:26, 19 March 2026 (UTC)Reply
Thanks for clarifying. I think all of the proposed solutions would be improvements, Support Support. -- LCU ActivelyDisinterested «@» °∆t° 15:37, 19 March 2026 (UTC)Reply
None of the proposals yield meaningful names. How about one of these?
  1. Use an |id= parameter if present
  2. Use a |ref= parameter if present
  3. Allow the editor to specify the name
I believe that any of these would be better than a generated name. -- Chatul (talk) 14:43, 19 March 2026 (UTC)Reply
@Chatul what's the difference between our proposal on content-based reference names and your ideas 1 & 2? It would be up for the communities to define which template parameters should be used to automatically create a reference name.
We are aware of the desire to allow VE users to manually change/create a reference name, but that's out of scope for our team, as it involves complex changes to the existing VE citation workflows. Johannes Richter (WMDE) (talk) 15:35, 19 March 2026 (UTC)Reply
We used to be able to name refs manually in the visual editor. I no longer remember why it was removed. WhatamIdoing (talk) 07:08, 30 March 2026 (UTC)Reply
According to phab:T52568 it used to be possible to assign a name when manually creating a new reference – but not when modifying an existing reference (which also applied to re-using existing references where the name is needed the most). The option to name references while creating them got removed a few weeks after that ticket was filed in 2013. And it seemed to only apply to basic references, as the VE citation tool opens the template dialog right away (same with reference created using Citoid). Johannes Richter (WMDE) (talk) 09:58, 30 March 2026 (UTC)Reply
Support Support the general idea of creating more meaningful names. But details seems a little fuzzy to me... Would you be using per template parameters map to know what is what (e.g. which param is an author, which is an URL)? So perhaps {"maps": {"citoid":...} from templatedata? Or something the template generates within a hidden element? E.g. did you consider using something generated in Lua by communities like: <span class=cite--basename style=display:none>Doe, 1998</span>? Perhaps use `.cite--basename` when available and fallback to citoid maps? My main concern is that we have a generic template (Cytuj) which supports all types of citations (types of documents) at the moment. And also – would you be willing to use spaces rather then underscores? Nux (talk) 15:43, 19 March 2026 (UTC)Reply
Thanks for your detailed feedback! We would most likely use TemplateData, because that's already used for Citoid and the VisualEditor citation tool. But we are interested in hearing other suggestions.
I've noticed that plwiki only uses one default citation template – don't think that's a problem? It would affect reference names based on solution 1, but there shouldn't be issues with the content-based solution? We would likely allow communities to define a fallback chain of different template parameters in case the preferred parameter hasn't been used in a citation.
We believe underscores make it easier to detect auto-generated reference names in case wikitext users want to improve them. But we are open to consider spaces (or hyphens) as well. Do you think it should be community configurable? Johannes Richter (WMDE) (talk) 16:28, 19 March 2026 (UTC)Reply
I think you could add ":” to distinguish from manually added names. I won't oppose underscores, but as with wiki links I prefer spaces. Nux (talk) 19:03, 19 March 2026 (UTC)Reply
Support Support Your effort generally, almost anything you do will be better than :0. Johnjbarton (talk) 15:47, 19 March 2026 (UTC)Reply
Support Support. Anything is better than the garbage :0 names. HouseBlaster (talk • he/they) 16:54, 19 March 2026 (UTC)Reply
Oppose Oppose I don't really see any improvement beyond fixing a cosmetic issue. Reference names are supposed to make it easier to see and track references without having to look up where it appears in full. The solution with ":0" -> "book_1"/"reference_1" offers no real change to this issue - it does not allow easy identification of the references. Auto-generated citation names also don't sound great, consider the automatic citations sometimes take incorrect info as the author or webname. This seems to just be a Pandora's box of how to correctly generate the names; besides that, this all sounds easy in practice, but we'll then need to set different names for different languages depending on various templates etc., of which there might be a multitude on different Wikis. Seems like a really messy process without any real advantage to me. If anyone is bothered by ":0", switch to source for 10 seconds and replace /":0"/ with what you want instead. The real improvement would be the ability to click the citation and set what you want the reference name to be directly (this solution is listed in the MediaWiki message, but I don't see it in the proposal; maybe I just missed it). KormiSK (talk) 19:57, 19 March 2026 (UTC)Reply
@KormiSK the proposed default names already exist in different languages, see [1] for translations of book reference etc in your language.
Could you elaborate on your issue with the proposed content-based names? If a user in VisualEditor re-uses a reference (which currently leads to <ref name=":0"</ref> if the reference doesn't already have a name), wouldn't we assume that information like the author name in the existing reference is correct (or that they fixed it before saving the edit, if the reference was generated using Citoid and the initial output had some flaws)?
I'm sorry if my village pump notification lead you to believe we are considering to add a feature for manually changing reference names in VisualEditor, that is out of scope for our team. I was only talking about a) providing better default names (either based on the reference type or defined by the community) or b) auto-generate names based on the reference content (domain or template parameters). Johannes Richter (WMDE) (talk) 20:26, 19 March 2026 (UTC)Reply
@Johannes Richter (WMDE): For Slovak, 7 of those translations exist; 2 are in Czech; and 3 don't. I don't know how to select and find those to fix them and no, the "translate" button is not helpful at all (finds everything else but the thing that needs translating). I'm at a loss of how to fix translations for skwiki specifically and this has been a long standing issue for me personally (and the project, half our stuff is in Czech).
Either way; many times, especially for newer users, they don't bother fixing citations. The automatic citations put in stuff like "AS Press" as the author name, when it really should be a normal name. I don't think assuming this information is correct - or filled in at all - is necessarily reasonable. Yes, it should be filled in, but more often than not on the project where I spend most of my time, I'm not so sure about it. It's also problematic the moment you get multiple sources from the same author, which is quite common for topics within science, where you cite multiple papers from one person. The system also completely breaks with Harvard citations, such as en:October 1907 Russian legislative election.
No worries about the notif. It would be the cleanest solution, just to click on the reference and in the pop-up select reference name. Alas. KormiSK (talk) 22:18, 19 March 2026 (UTC)Reply
@KormiSK you can change those translations on translatewiki [2] (requires creating an account, your Wikipedia login doesn't work there) – noting that the link also includes some messages which aren't relevant to our proposal (e.g. the "gadget-conflict" messages).
I don't see how the proposal would break with harvard citations, that seems to be one of the easiest templates for implementing the proposed content-based solution, e.g. by communities defining that the reference name should be based on the parameters last1 + year + page (if the last one exists) when using en:Template:harvp?
The current workflow for re-using references in VisualEditor involves no interaction with the reference that would naturally prompt users to click on the reference again to change it's name from ":n" to something useful. Rethinking those workflows is out of scope for our team, we can only offer to improve the automatically generated names if the community want's us to do so. Johannes Richter (WMDE) (talk) 07:06, 20 March 2026 (UTC)Reply
@Johannes Richter (WMDE): I just find the effort to be a waste of time personally, but ultimately I don't care what the nomenclature used for references is. The only good solution in my opinion would be to implement a button here, where you could specify a reference name, alongside the groups, maybe in a way where it's not possible to add a reference if you do not fill this name in. The only issue I really see being fixed here is the copying of references between articles, where you potentially reuse an unwanted citation. Ultimately, the solution here should minimize such errors. Otherwise, I'd rather the name be taken from the title of citation - I like the Zotero-related idea proposed below.
Re: translations, that's a topic for elsewhere, but as I said, I am unable to find the needed translations in order to translate them. I have a translatewiki account, that's not the issue here. KormiSK (talk) 12:19, 20 March 2026 (UTC)Reply
Support Support the content-based solution. The reference type will not add too much value, as many articles lean towards using mostly the same type of references (scientific articles use papers, recent politics uses news). Making it configurable is smart, as it allows for a wide variety of templates across languages. Defaults of using author, then publisher etc could be similar to existing tools. I like the fact that VE editors don't have to choose themselves, as it's not a visible bit of their editing experience. —Femke 🐦 (talk) 20:21, 19 March 2026 (UTC)Reply
Thanks for your feedback @Femke. Would you want to keep ":n" as the fallback reference name if it's not possible to create a content-based name (e.g. if it's a basic reference without a URL) or do you think the first proposal would still serve as a better fallback compared to the status quo, even if it doesn't add much value in your opinion? Johannes Richter (WMDE) (talk) 20:30, 19 March 2026 (UTC)Reply
No strong preference there. Work to implement that fallback might be better spend on finessing the content-based solution. —Femke 🐦 (talk) 22:26, 19 March 2026 (UTC)Reply
Support Support the general idea, one of my favourite scripts is en:User:Nardog/RefRenamer which renames refs [last name]-[year], eg. Anderson-2008, and disambiguates refs by the same author using letters, eg. Anderson-2008a, Anderson-2008b etc. Kowal2701 (talk) 20:22, 19 March 2026 (UTC)Reply
Support Support any solution, but i prefer content based solutions. BrokenSegue 20:23, 19 March 2026 (UTC)Reply
Support Support the direction that this is going. The six bullet points under "Proposed solutions" make a lot of sense and any solution that follows them will be a worthwhile improvement over the status quo.  Weak support proposal 2 in particular. I would prefer shortened versions of parameters to be an option rather than the whole parameter. That would probably be the first or last word of the parameter, which could be used, for example, to extract the last names of authors, or to shorten the title of articles. Even better would be to combine shortened parameters. This is more in line with how dedicated citation software tends to handle IDs: for example, Zotero makes the id "efron_bootstrap_1979" for this citation:
Efron, B. (1979). Bootstrap Methods: Another Look at the Jackknife. The Annals of Statistics, 7(1), 1–26.
I'm not saying we need to exactly copy Zotero: in general, the data that Wikimedia has available for citations is less structured than Zotero, which makes these kinds of descriptive IDs harder. Still, Zotero's ID system is the most intuitive and helpful I've worked with for citations, and I'd prefer to see something a bit closer to it.
Eiim (talk) 20:38, 19 March 2026 (UTC)Reply
Support Support change from the current very bad system. The concept of a "fallback" should be made unnecessary/redundant by having a tiered system of some kind, so there is an inherent fallback within a hierarchy. I will not repeat all good points above, but I would like to emphasise Eiim's point that the default name should combine multiple parameters where possible. This greatly increases identifiability while also greatly reducing the chance of conflicts. CMD (talk) 11:43, 20 March 2026 (UTC)Reply
Support Support i am fixing bare urls as a start using android app. please consider stripping |title= to maximum 100 characters or community decision. it must not occupy too much screen space for ref name. কল্কি (talk) 00:49, 23 March 2026 (UTC)Reply
@কল্কি we will definitely introduce a character limit when implementing the content-based solution to avoid edge cases which lead to very long reference names. I'm curious what other users think: Do you believe 100 characters is a reasonable limit or should it be more/fewer characters? Do you think the number should be community configurable or is it ok to define a limit that applies to all wikis? We are currently planning to use the fallback reference name when the content-based solution would exceed the character limit – do you think we should still use the content-based name and just omit those characters exceeding the limit? Johannes Richter (WMDE) (talk) 10:13, 23 March 2026 (UTC)Reply
@Johannes Richter (WMDE) my first choice was only 40, but i thought 100 would be nice round figure! it must be definitely community configurable. my suggestion is biased, android app team might have statistics (analytics cant be disabled as per fdroid) about percentage of mobile minimum and maximum screen size. engaging community wikis based on analytics and fall back to content-based name is the best choice. কল্কি (talk) 14:13, 23 March 2026 (UTC)Reply
Oppose Oppose option 1 for the reasons explained briefly below Support Support option 2 if that's not just like <ref name="Olympics.com"> but rather sth like <ref name="Olympics.com-2025-02-ITs-Your-Vibe--the"> for example as what's described in the two Community Wishlist wishes linked below. Prototyperspective (talk) 14:42, 23 March 2026 (UTC)Reply
Thanks for your feedback @Prototyperspective! It's of course up for local communities to define which template parameters to choose for the reference name.
Note that we need a fallback for non-templated references. Without reliable indicators like template parameters it's impossible for us to determine reference information like the title given that citation styles vary across different languages and different wikis. That's why we proposed using the domain (if a URL exists) for non-templated references, that's pretty much the only information we can reliably extract without templates. Do I understand you opposition to option 1 correctly that you would prefer using :0 as a fallback for all references without a template and without a URL? Johannes Richter (WMDE) (talk) 15:28, 23 March 2026 (UTC)Reply
No, there for new refs (not changing existing :0-style-named refs) book-1 etc would be better than :0 :1 etc. However, maybe there is a way to check if an URL is present and if so use that for the ref name. Some sites would need to be exempted like Internet Archive (or just the archived site's domain) or Google Books. Prototyperspective (talk) 16:28, 23 March 2026 (UTC)Reply
Checking for the URL and using the domain as a reference name is part of the content-based proposal. If there's no template or if the community hasn't defined which template parameters to use we'll check for a URL and only if there's no URL and no template we'll use the fallback.
Thanks for your suggestion regarding Internet Archive and Google Books, that's an edge case we've thought about as well, we still need to figure how to deal with them (from a technical perspective – we are aware that archive.org ref names are not ideal). If we cannot find a good solution for those websites, would you rather want us to not use archive.org as a domain at all (and use the fallback instead) or do you think a couple of archive.org ref names would be acceptable? Johannes Richter (WMDE) (talk) 18:31, 23 March 2026 (UTC)Reply
Good to hear; it would be acceptable I think but the URL of IA archived sites follow standardized formats so one should be able to get the domain of the archived site quite readily. Prototyperspective (talk) 18:37, 23 March 2026 (UTC)Reply
Procedural note: The above passages were inadvertently removed in this edit. I've belatedly restored them (and this is not a great look for the diff detector, because this was certainly not something intentional, nor was I warned about a merge conflict...) SnowFire (talk) 05:05, 8 April 2026 (UTC)Reply
Long ref names, especially long names that are semi-random strings of numbers and letters, are very irritating to editors who are working in the wikitext editor. People want to be able to type things like <ref name="Smith"/>. The do not want to have to type, or even look at, <ref name="Olympics.com-2025-02-ITs-Your-Vibe--the">. WhatamIdoing (talk) 07:12, 30 March 2026 (UTC)Reply
Partial Support Support, partial Neutral Neutral. Anything is better than the :0, :1 names. But why are we walking down this same path with book-reference-1, which is only marginally better? That's just the same thing but longer, especially in articles where say most of the references might be news references. Use RefRenamer style names instead, so AuthorLast-Year. Or even AuthorLast-Year-n if you want to count up for multiple references to the same author in a year. If there is no author, default to work; if there is no work, then we can do the really basic "book" or "magazine" names. SnowFire (talk) 16:08, 23 March 2026 (UTC)Reply
@SnowFire that's the idea – if the community agrees to our content-based ref name proposal we would implement a solution allowing local communities to define which template parameters to use for automatically creating a reference name when re-using unnamed references in VisualEditor. The simple option (e.g. book_reference-1) is a proposal for non-templated references and other edge cases (and to offer an alternative in case the community rejects the proposed content-based solution). Johannes Richter (WMDE) (talk) 16:20, 23 March 2026 (UTC)Reply
Yes, but these will still create vague references like "bbc" for any ol' story from bbc.com . I think it is very important for there to be sane defaults. The whole point of this will be to make it easier to reuse references when they are something useful like "Richter-2025-1", so we should use the standard and informative LastName-Year first. The vast majority of projects won't reconfigure these, or it'll be a bureaucratic hassle to adjust. So let's actually fix the problem we're trying to fix. SnowFire (talk) 14:35, 24 March 2026 (UTC)Reply
Citation templates vary a lot across different wikis (and even on a single wiki there are lots of different citation templates) – without local communities configuring which template parameters to choose there's no way for us to determine the correct parameters... Johannes Richter (WMDE) (talk) 14:49, 24 March 2026 (UTC)Reply
"Richter-2025-1" or [last name]-[year] when we say year, is it webpage published year or when webpage was accessed year or something else. my limited experience with citations is limited but almost 10% of citations created by citoid lack webpage title due to poor metadata. the irony, for most of india govt. websites, metadata has lang=en-US. there will be more examples which i am not aware. if we are going to use year, it must be current year. for ex. all citations created using this new method in calenday year 2026, must contain 2026. this way we can keep track number of citations created or if any issue crops up, we can fix it easily.
কল্কি (talk) 08:16, 30 March 2026 (UTC)Reply
We would strive to allow communities defining fallback chains of different template parameters in order to cover at least some of the citations with certain template parameters not filled out. Johannes Richter (WMDE) (talk) 10:01, 30 March 2026 (UTC)Reply
Support Support any change from the existing system, which is preferable to the generic names we have now. I prefer the content-based system, but realistically, any reference name that gives a minimal amount of information about the reference would be good. There are some projects, like the English Wikipedia, that actively discourage the types of names VE generates by default. Epicgenius (talk) 13:57, 30 March 2026 (UTC)Reply
  • Support Support But please do not replace the current meaningless citation variable naming system with another inhuman system. Keep the humanity and human readability in Wikimedia projects, and assign citation names following traditional human citations systems. For example, author last name and year are familiar and common abbreviations for in-text citations. I am aware that these names will only be visible to editors, but still, try to adopt an existing system proven to work rather than devise new naming conventions. Bluerasberry (talk) 16:25, 30 March 2026 (UTC)Reply
    Thanks for your feedback @Bluerasberry! Just to make sure there's no misunderstanding: It would be up for local communities to define which template parameters to use. Based on our investigation of ref name guidelines across different wikis, it seems most wikis recommend variations of "author-year", but given that citation templates and citation styles differ across wikis, we wouldn't even be able to just define a rule that applies to all projects (except for the fallback proposed in solution 1 / 1.1 if proposal 2 doesn't lead to a meaningful name, e.g. because the citation doesn't use a template / URL to derive the name from). Johannes Richter (WMDE) (talk) 09:04, 31 March 2026 (UTC)Reply
  • Support Support soltuion 2 or something along that lines.
    The dumb :0 "names", which are not really names, but just meaningless numbers without any connection to the reference, are of course ugly as hell, but just putting one more contentless word in front is not really an improvement.
    Any word or phrase from the reference is better then those dumb numbers, best would be probably a word by the users, they know best, but any proper word is better then just the number.
    In the deWP we usually don't use cite-X-templates, except in some not really good translated articles from enWP, they work, but we frown about them. The Vorlagen are Literatur, Internetquelle, and all should contain some plain text, not just naked URL, but that's of course as well possible. How will that be catered for, localised templates?
    I never work with VE, I always use the normal text editor, or some low-key derivates like this Neuer Abschnitt or Beantworten, but inside with wikitext, so I'm just confronted with this disgusting numbers if I alter some text. And those numbers say absolutely nothing about the reference, imho it should be a word and a date or such, something content- or source-related. But anything is better then the existing stuff. Grüße vom Sänger ♫(Reden) 16:30, 30 March 2026 (UTC)Reply
    @Sänger thanks for your feedback. We are aware that "cite ..." is not a standard across all wikis, dewiki uses de:Vorlage:Internetquelle and de:Vorlage:Literatur, plwiki uses pl:Szablon:Cytuj... Local wikis would be able to define which template parameters VE should use to auto-generate the ref name, probably via TemplateData (but we haven't decided on the technical approach yet).
    German summary: Danke für dein Feedback, wir sind uns natürlich bewusst, dass "Cite ..." nicht in allen Wikis existieren und dewiki beispielsweise Vorlage:Literatur nutzt. Die jeweiligen Wikis würden bei Vorschlag 2 definieren können, welche Vorlagenparameter VE für den ref name nutzen soll (wahrscheinlich via TemplateData). Johannes Richter (WMDE) (talk) 09:29, 31 March 2026 (UTC)Reply
    OK, but what about the essentially identical to the current b***s*** "solution 1", that just puts more meaningless stuff in front of the meaningless number? You can ditch that completely, as it's the same, but longer. With or without another random word in front of the number is completely irrelevant, solution 1 is no solution to anything, it's just bloatware.
    Auf gut Deutsch: Die komplett merkbefreite "Lösung 1" ist nichts anders als der aktuelle Zustand, nur aufgebläht um ein willkürliches weiteres sinnfreies Wort vor der willkürlichen sinnfreien Nummer. Das ist nur Aufblähung ohne jeden Sinn und Verstand, das Wort ändert rein gar nichts. Grüße vom Sänger ♫(Reden) 13:07, 31 March 2026 (UTC)Reply
    @Sänger there are lots of references which don't use a template and don't include a URL and therefore don't offer a way for us to automatically create a meaningful reference name according to solution 2 that works across all wikis. There might also be edge case where we need a fallback even if the citation uses a template or a URL. We can either keep :0 as a fallback or go with solution 1 / 1.1 instead which would allow for ref names like "Einzelnachweis-1" on dewiki (or another fallback name defined by the community). That's similar to some community-developed features (e.g. AutoWikiBrowser) which also offer a fallback if there are no template parameters to use for reference names (AWB's fallback is "ReferenceA").
    We believe solution 1 / 1.1 would be an improvement compared to the status quo, as the naming scheme ":n" feels like wikitext and is cryptic to contributors, while "reference-1" is easier to read (and translatable for different wikis).
    It's up for the community to decide if they would rather keep the current naming pattern as a fallback if VE can't create a meaningful name or if they see solution 1 / 1.1 as a slight improvement. Johannes Richter (WMDE) (talk) 13:43, 31 March 2026 (UTC)Reply
    Just take the first 5-10 letters of the text (just ditch an http://), that's in the ref, even that's better the current solution, or the same solution 1. Grüße vom Sänger ♫(Reden) 14:23, 31 March 2026 (UTC)Reply
    I don't think that <ref name="books.goog"> is better than <ref name="book1">.
    Ich glaube nicht, dass <ref name="books.goog"> besser ist als <ref name="book1">. WhatamIdoing (talk) 20:13, 31 March 2026 (UTC)Reply
  • Support Support any change from the existing system, as per the reasons provided by several users above.--Naḥum (talk) 16:46, 30 March 2026 (UTC)Reply
Oppose Oppose to proposal 1 for reasons like KormiSK: a longer, complicated name with a combination of underscores, dashes and numbers doesn't make it easier for anybody. It doesn't make my life easier whether if have to check what is ref name=":0" or what is ref name="news_reference-4". But it does make my life more difficult because I have to remember many more characters. And BTW: these templates are hardly used in German Wikipedia.
Support Support to proposal 2.
It would be helpful to have an option in the VisualEditor to copy the code of a reference with one click to easily add it into templates.— The preceding unsigned comment was added by Albinfo (talk) 16:45, 30 March 2026 (UTC)Reply
Thanks for leaving your feedback @Albinfo! Regarding "hardly used" templates: As of May 2024 there were 2,768,906 references on German Wikipedia using de:Template:Internetquelle (= {{cite web}}) and 789,215 references using de:Template:Literatur (= {{cite book}}) [3]. If we can't generate a meaningful reference name according to solution 2 (because a citations doesn't use a template and doesn't include a URL), you would rather go with ":0" instead of proposal 1 / 1.1 as a fallback, correct?
I'm not sure I fully understand your feature request about copying the code of a reference in VisualEditor (are you asking about something like phab:T95702?), I'll follow up on your dewiki talk page.
German: Danke für dein Feedback Albinfo! Bzgl. "hardly used": Im May 2024 wurde Vorlage:Internetquelle in der deutschsprachigen Wikipedia in 2.768.906 Einzelnachweisen genutzt und Vorlage:Literatur in 789.215 EN. Wenn wir keinen sinnvollen Namen gemäß Vorschlag 2 erstellen können (weil ein Beleg weder eine Vorlage noch eine URL nutzt), würdest du also weiterhin ":0" als Fallback nutzen wollen, anstatt Vorschlag 1 / 1.1, richtig?
Ich bin mir nicht sicher, ob ich deinen Wunsch bzgl. VE korrekt verstehe (meinst du sowas wie phab:T95702?), ich schreib dir dazu auf deiner Benutzerdisk. --Johannes Richter (WMDE) (talk) 08:53, 31 March 2026 (UTC)Reply
Für {{cite news}} haben wir aber in DE kein Äquivalent. Und {{cite web}} ist neben {{Internetquelle}} auch in Verwendung. Aber wenn ihr das auf dem Radar habt, ist alles gut.
Wäre dann Vorschlag 1 in einem solchen Fall "internetquelle_reference-1"?
Yes, I would prefer ":0" instead of proposal 1, a rather complicated and very long sequence of 16 or more (up to 26?) characters. Albinfo (talk) 22:19, 31 March 2026 (UTC)Reply
More regarding the feature request on my German discussion page. Albinfo (talk) 22:19, 31 March 2026 (UTC)Reply
Vorschlag 1 wäre "Internetquelle-1" bzw. "Literaturquelle-1" für alle dewiki-Einzelnachweise, die über ihre Vorlage die cite class "web" bzw. "book" erhalten. Johannes Richter (WMDE) (talk) 09:11, 1 April 2026 (UTC)Reply
Support Support any change from the existing naming system. I would favor "solution 2" as it seems the more simple way to easily recognize.--Afernand74 (talk) 17:01, 30 March 2026 (UTC)Reply
Thanks for the ping.
"web_reference-1" is only marginally better than the current system. The ideal, where possible, should be "Surname-year" (e.g. "Mabbett-2010"), using the surname of the first listed author; and "Surname-year-b", "Surname-year-c" if there are more than one source with the same name and year.
If there is no author name (as is often the case for websites), then use either the website name (e.g. "CNN-2026") or a word or words (or, say, the first ten characters) from the title, substituting hyphens for spaces.
In all cases, the user should be able to change or override the suggested name, when supplying a new source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:14, 31 March 2026 (UTC)Reply
Solution 2 would cover these suggestions (if local communities define template parameters like author + year as the desired ones). Solution 1 would only serve as a fallback if we can't create a meaningful name (e.g. because communities didn't configure which template parameters to use) – otherwise we would need the current naming pattern ":0" as a fallback.
Our team can only offer to improve automatic reference names, we won't be able to implement feature requests to allow manually changing ref names in VE. If users want to "override" the automatically created name, they'll need to switch to wikitext. Johannes Richter (WMDE) (talk) 14:26, 31 March 2026 (UTC)Reply
The second paragraph in your RfC includes: "We are happy about suggestions for improving certain details of the proposed solutions. Any other feedback and alternative proposals are also welcome – even though it’s out of scope for us, it might still be relevant for future work on this topic." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:39, 31 March 2026 (UTC)Reply
Indeed, just wanted to make sure there's no misunderstanding about what to expect from our proposed improvements right now :) Johannes Richter (WMDE) (talk) 15:04, 31 March 2026 (UTC)Reply

Oppose Oppose Proposal 1 - these new names are almost as useless as VE's current names, and would not justify any time spent developing software to produce them. PamD (talk) 20:34, 30 March 2026 (UTC) Support Support Proposal 2 as better than the current awful ref names, but strongly encourage an approach which would produce better names by using a set of rules similar to those of RefRenamer, so that a ref containing an author surname (book, journal article, etc) is named with the author's name, perhaps plus date, plus any further necessary disambiguation if there are multiple refs from same author. PamD (talk) 20:34, 30 March 2026 (UTC)Reply

@PamD thanks for your feedback! Local communities would be able to define the set of rules for their citation templates (probably via TemplateData, but we haven't decided on the exact technical approach yet), that way solution 2 will work on all wikis and with all kinds of templates.
But given that some citations don't use templates (some smaller wikis don't even have citation templates) and book citations usually don't include a URL, we still need a fallback – we imagined solution 1 / 1.1. could be desired over the status quo (:0) if we fail to generate a meaningful name (see #When the ref has no citation template). Do I understand you correctly that you would rather go with :0 if we can't generate a better name? Johannes Richter (WMDE) (talk) 08:19, 31 March 2026 (UTC)Reply
@Johannes Richter (WMDE) If solution 1 is the best you can come up with then it doesn't seem worth the effort as it's still just a number, albeit with more characters of uninformative text wrapped around it, and will not help an editor to match it to a reference. PamD (talk) 12:07, 31 March 2026 (UTC)Reply
Support Support Just do it, it's good enough. — The preceding unsigned comment was added by Johnjbarton (talk) 20:08, 1 April 2026 (UTC)Reply
  • Support Support Proposal 2, Neutral Neutral Proposal 1. Proposal 2 is really what we're looking for. Proposal 1 is not really a solution, but as it is marginally better than the current format I won't oppose it. I encourage WMDE folks to limit the resources spent on developing Proposal 1, even as a fallback for Proposal 2, due to its limited utility. What I don't understand, though, is why we can't have sensible names regardless of templates. Ignoring the parameters entirely, shouldn't it be possible to write Regex or a more complicated algorithm to identify the first word in a citation (which is most likely to be an author's name) and the first four-digit number (which is overwhelmingly likely to be a year) and make a citation name out of that? Even when it fails by, say, pulling the first word of the title and an access year, at least we'll get something slightly recognizable and derived from the source itself. I'm concerned that Proposal 2 will leave out small wikis who do not have the technical expertise or awareness to set up the required configuration, leaving them with the half-baked solution of Proposal 1. Toadspike [Talk] 09:35, 2 April 2026 (UTC)Reply
    Since the point of ref names is to make them easier to use in the source editor, and source editor users have (reasonably) complained about the length of the names generated by Proposal 1, I strongly suggest reducing "reference" to "ref", for example: "web_ref-1". Toadspike [Talk] 09:40, 2 April 2026 (UTC)Reply
    @Toadspike thanks for your feedback! Citation styles vary across different languages and different wikis. While your idea for non-templated references might work on enwiki, we wouldn't be able to ensure that it's producing equally acceptable results on all other WMF wikis. There are other edge cases to consider as well (really long words, short words like initials...) -> #When the ref has no citation template.
    You are right, small wikis are less likely to implement the necessary template changes for solution 2, although parts of solution 2 (creating a name based on the domain if the reference uses a URL) would work across all wikis without configuration and even for references without a template (which are much more frequent on small wikis). Small wikis who use citation templates often create copies of enwiki citation templates – ideally they could just copy the enwiki configuration for solution 2 while doing that. We might be able to assist smaller wikis updating their templates based on enwiki's configuration if desired.
    Is the ref name length that much of an issue for proposal 1? "author-year" or "domain-year" as currently used on many wikis doesn't seem (much) shorter than "web_reference-1" – in fact automatic ref names based on solution 2 might even lead to edge cases with much longer names (see my question in #Content-based reference names edge cases about a potential character limit).
    Regarding "web_ref-1" instead of "web_reference-1": Our idea was to re-use existing translations for reference types. While shortening sounds reasonable when looking at enwiki (e.g. [4]), it wouldn't work on other wikis (e.g. [5][6][7])... Johannes Richter (WMDE) (talk) 10:05, 2 April 2026 (UTC)Reply
    The length comparison seems strange: by "author-year" you mean something informative like "Smith-1952" or even "Hovhannisyan-1901"; "web_reference-1" is almost as uninformative as ":1". If the ref name doesn't have any identifying content related to the ref itself, it's almost as useless as VE's current names. PamD (talk) 10:47, 2 April 2026 (UTC)Reply
    Thanks for the reply, Johannes. Obviously you can't "ensure" anything across hundreds of wikis in hundreds of languages. My point is that even taking any two random strings (perhaps with a cutoff at ~16 characters) from a citation will likely produce a more informative and certainly more unique citation name than what's currently proposed in Proposal 1. Any editor could then tell which citation is being referred to by the citation name; they'd never be able to tell which numbered "web_reference-n" it is from the citation alone.
    Yes, name length is an issue. If you have an opportunity to take off 6 repetitive characters from all ref names, which are intended to be hand-typed, I can't comprehend why you wouldn't take it. I don't see what you're trying to say in the last sentence or what you're trying to show with those links. If you're trying to say that the English word "reference" is somehow less unnatural in non-English languages than the abbreviation "ref", I cannot agree.
    Thank you for the offer of support for small wikis. Toadspike [Talk] 11:50, 2 April 2026 (UTC)Reply
    I was trying to say that automatic ref names based on proposal 1 would be "web_reference-1" on enwiki, but e.g. "Internetquelle-1" on dewiki -> other languages wouldn't allow abbreviations like "web_ref"... Johannes Richter (WMDE) (talk) 12:02, 2 April 2026 (UTC)Reply
    @Toadspike, having code that works on all languages is very difficult. For example, can you write regex that finds the first word in this citation?
    I can't. I can't even tell you where the different words start and stop, because this language doesn't put spaces between words. I definitely can't tell whether cutting it off in the middle of a word would result in something irrelevant or inappropriate.
    The only valid assumptions about the content are that it will contain some sort of text and that it's going to be inconsistent and unhelpful. It will be bare URLs. It will be templates missing most of the information. It will be manually written. It will contain typos and errors and misplaced items (e.g., "Dr. Alice Expert" instead of "Expert, Alice"). It will be various shorthand codes that are appropriate to the field or culture (e.g., "U.S. Const (art. I, § 8, cl. 8.)" or "Symposium 172a" or "Genesis 1:10"). It will be explanatory footnotes instead of bibliographic citations for sources. In short, some of it will be definitely be an unparse-able mess. I think we need to have a plan for what to do in such situations, even if that plan is just "keep using the ugly old :0 method when it can't be parsed". WhatamIdoing (talk) 18:44, 2 April 2026 (UTC)Reply
    I can't write any regex, so the answer to that question doesn't tell you anything. But in a case like this, there is absolutely nothing with simply taking all of "太阳非常大" and plopping it into a citation name. You could even just take the first n characters, without trying to filter for words. All of that would be better than Proposal 1. Toadspike [Talk] 20:28, 2 April 2026 (UTC)Reply
    What if the first n characters has a different meaning? What if that different meaning is undesirable? This could be a w:Scunthorpe problem, but it also could be irrelevant. 太阳非常大 is a machine translation of "The Sun is Very Big" (a book title we invented at the English Wikipedia years ago), but machine translation says "太阳非" means "The Sun is Not", and the second character by itself has multiple meanings, at least one of which is vulgar. You can't just chop off letters and assume all will be well. You will end up with useless bits (ref name="Another") and embarrassing bits and repetitive bits (ref name="The").
    The median English Wikipedia article has just 4 refs, with a mean average of 9. The odds of having multiple books is low in most articles. Thus the question isn't really about having ref name="book 42"; it's really about whether you would you rather have ref name="book 1" or whether you would rather have something potentially wrong, embarrassing, or equally useless whenever it's not possible to do better? WhatamIdoing (talk) 21:52, 2 April 2026 (UTC)Reply
    I personally don't see this as a problem. In your example it isn't, since 太阳非 is in no way obscene. But even if it were, this is something that all readers and most editors will never see. To the remaining few, who see something like "association" get chopped down to "ass", we simple explain that it's a machine-generated name with technical limitations for usability, with a reference to WP:NOTCENSORED if needed. Or what, we start banning citations of authors called "Hell" or "Dick"? Toadspike [Talk] 17:38, 3 April 2026 (UTC)Reply
    I wonder how many of those unfortunate names would trip Special:AbuseFilter or an anti-vandal bot, especially if they're done by a new editor. WhatamIdoing (talk) 17:49, 3 April 2026 (UTC)Reply
  • Support Support but the better names suggested by WhatamIdoing and SnowFire would be an improvement. Though does it even matter if some reference names end up being unfortunate? — OwenBlacker (Talk; he/him) 09:06, 4 April 2026 (UTC)Reply
    Are you willing to explain over and over, for years to come, why Wikipedia put a rude word in the wikitext? Or to defend editors who had no control over it and are now being blamed for "their choice" of misleading/profane/racist/sexist ref names? WhatamIdoing (talk) 18:56, 4 April 2026 (UTC)Reply
    Does it matter, given it's trivially easy to change? Bad words lists are notoriously difficult and unreliable in just 1 language, let alone nearly 350 languages.
    But I don't think we're likely to see people asking, over and over, or people being blamed for "their choice" of words. It'll just get fixed, the same as vandalism would do. — OwenBlacker (Talk; he/him) 21:53, 4 April 2026 (UTC)Reply
    I don't think so. Yes, it may get fixed, but "the same as vandalism", the innocent editor will get blamed for something outside their control, and that matters. When the visual editor was deployed in 2013, it regularly screwed up certain features in articles (e.g., ship-related infoboxes at the English Wikipedia). A whole lot of editors, especially newer ones, got blamed for those problems, even though they had no idea what caused it or how to fix it. The problem persisted until all the blame-casting experienced editors learned that their accusations were misplaced (and, in the case of {{Infobox ship}} in particular, the infobox got re-written). On the way to that happy end, we spent a lot of time reassuring the innocent editors, fixing the problems, and educating the mistaken accusers.
    IMO a "bad word list" is not hopeless (Title blacklist is probably a good starting point), but it is insufficient. That's one of the reasons that I think ref name="book 2" would be a less drama-prone approach for non-templated refs. WhatamIdoing (talk) 22:17, 4 April 2026 (UTC)Reply
Support Support option 2: I like adding year after a last name or a journal e.g. ref name=Smith2019 or ref name=NEJM2025. That combination is in almost all cases good enough in an article and will not result in duplicates. No strong opinion on quote marks in ref name: don't know enough about the technical limitations to it. No strong opinion on automatic hyphen/dash in ref name. --Treetear (talk) 19:06, 7 April 2026 (UTC)Reply
If you don't type the quotation marks in the wikitext, then the server silently adds them when processing the page. Supposedly it's a little bit gentler on the servers if we put the quotation marks in the wikitext, and therefore the visual editor always adds the quotations. (Also, it's the "correct" thing to do, in terms of HTML standards.) WhatamIdoing (talk) 19:55, 7 April 2026 (UTC)Reply
Support Support in general, regardless of how the details are ultimately implemented. Perhaps, as has already been suggested, the “author year” format—e.g., “Maier-2005”—would be better for literary and online sources? Especially for literary sources, this looks much more professional. Also, a little field in the visual editor for editing the ref name would be cool (which probably would not be possible in single-section-edits). Either ways, a cool suggestion! --Ovinator (talk) 14:31, 10 April 2026 (UTC)Reply
Support Support the content-driven system. I think that the content-based reference names (second proposal) will resolve this old nuisance and reduce significantly the need to substitute the meaningless automatic reference names. I'd like to see <author name>-<year> format for books and short URL format for links. Only when it isn't possible to generate a proper reference name (e.g. lack of parameters) maybe would be better to retain the current system instead of shifting to a new one that use longer (and not so useful however) names. ZandDev (talk) 10:19, 16 April 2026 (UTC)Reply
Support Support Content driven names. ONUnicorn (talk) 15:58, 17 April 2026 (UTC)Reply
Support Support Content driven names - maybe first look for a word in the title that isn't already used, otherwise an author name-year combination. Oppose Oppose content type-number combinations: that's not much of an improvement on what we already have. --Slashme (talk) 17:46, 17 April 2026 (UTC)Reply
Support Support content-driven names, but these names must be concise and meaningful. Names that merely indicate whether a citation is a journal, book, or web page are not useful. Harvard-style reference tags (surname of the first author followed by the year) are more meaningful. Boghog (talk) 18:42, 17 April 2026 (UTC)Reply
Support Support option 2, content-driven names, ideally <author name>-<year> as noted above, otherwise <website>-<year> or similar. Alexcalamaro (talk) 20:38, 17 April 2026 (UTC)Reply
Support Support content-driven names. I would strongly support titles (where supplied) as they tend to be more unique but perhaps compressed to remove spaces and puncuation with truncation so they don't become too long , which would produce for the web example given "ITsYourVib" (using 10 as the max length). As a retired academic, I would comment that academic practice of shorthands like Smith1970 works ok for collaborating on academic publications which are written by either a single author or closely-collaborating small group of authors (you all know what work you are talking about), but I don't think it works atall well in the not-closely-collaborating world of Wikipedia. I think titles would generally be more helpful as they give another editor a bit better guess as to the likely content. But anything that improves the current way VE does it can only be a good thing! While I appreciate it is out of scope for this proposal, I really can't understand why the VE can't allow editors to supply a reference name of their choice when they add a citation. While I understand we want to keep VE simple for less experienced contributors, but why can't there be a Preference for VE that experienced editors can set to allow them to add a name to a new citation. Kerry Raymond (talk) 00:43, 18 April 2026 (UTC)Reply
Oppose Oppose proposal 1 as it adds little. Support Support for proposal 2, wonder if one could set up a MediaWiki interface message to customize how to prioritize the various parameters to pick. JoJo Eumerus mobile (talk) 11:20, 19 April 2026 (UTC)Reply

Hello,

I personally prefer the idea of content-based reference names, but I know from experience that all sort of things can end up in a template field. I would be interested in knowing how you would treat the following values for a parameter:

  • full (not too long) url
  • Text containing internal links
  • Text containing HTML tags
  • template transclusion
  • Some text randomly containing quotes in the middle
  • Emojis 🦊

Thank you, Escargot bleu (talk) 13:11, 19 March 2026 (UTC)Reply

Thanks for pointing this out, these are edge cases we've considered as well. We are confident that we can handle some of them, others would use the default name as a fallback (either solution 1 / 1.1. or the current pattern ":n", if the community just wants us to implement solution 2).
  • If the template parameter to be used for creating the automatic reference name contains a full URL, we would likely use the full URL as a reference name, unless that leads to a reference name we consider too long.
    • We've yet to define how many characters a reference name can have – do you have a suggestion? And do you think that should be community configurable or would it be ok set a limit that applies to all wikis? If the name is too long, we would fallback to the default name.
  • If the template parameter contains wikilinks, we would probably ignore them. Example: We would create ref name="Anne_Conway" if the template parameter is |author=[[Anne Conway (philosopher)|Anne Conway]], but ref name="Anne_Conway_(philosopher)" if the template parameter is |author=[[Anne Conway (philosopher)]]
  • We would probably ignore emojis as well.
The other edge cases depend on our technical implementation. Generally speaking: We would do our best to accommodate common edge cases, but those might be edge cases where we might turn to the fallback instead. We believe that would still be an impactful improvement compared to the status quo. Johannes Richter (WMDE) (talk) 14:03, 19 March 2026 (UTC)Reply
I suggest 40 characters as the absolute maximum: This will accommodate Wolfeschlegelsteinhausenbergerdorff plus one character for a space/separator, and a four-digit year. And 20, or even 10, would very frequently be preferable. WhatamIdoing (talk) 07:37, 30 March 2026 (UTC)Reply
In the case of multiple URL references with the same hostname, I suggest to add a date suffix (for example "Blabla.com_2026-04-02"), or just a number suffix if there's no available date (for example "blabla.com_01").
Also, maybe just skip the ".com" or ".net" subdomains if there's no country domain. And keep the ".org", ".edu" or other non-generic subdomains.
Thank you, --NaBUru38 (talk) 21:05, 2 April 2026 (UTC)Reply

I want to encourage you to consider the algorithm used by the RefRenamer tool. It resembles the naming that humans have done in print publications for a few hundred years and the naming used in most of the (ok scientific) wikipedia articles I have edited. The name is based on first_author_last_name-date. It does not work for every case but you already know that you need fallbacks. Johnjbarton (talk) 15:43, 19 March 2026 (UTC)Reply

Thanks for your suggestion! We are aware of RefRenamer and similar tools (e.g. Cite Forge). Most of them are specific to citation templates on certain wikis while we need a solution that works across all Wikimedia projects – that's why our approach for content-based reference names relies on local communities configuring which template parameters VE should use to generated the reference name. Johannes Richter (WMDE) (talk) 16:05, 19 March 2026 (UTC)Reply
I'm with Johnjbarton on this: RefRenamer produces meaningful names for references. If a different Wiki doesn't use the same templates, then let your new system adapt to the way it cites references. Do not create unnecessarily cumbersome reference names for wikis where RefRenamer's rules produces sensible results. PamD (talk) 20:31, 30 March 2026 (UTC)Reply
Speaking of cumbersome names, there's a question in another section about the maximum reasonable length of a ref name. WhatamIdoing (talk) 22:29, 30 March 2026 (UTC)Reply
"let your new system adapt to the way it cites references" – that's one of the ideas, local communities could configure which template parameters to use for automatically generated reference names. Johannes Richter (WMDE) (talk) 07:43, 31 March 2026 (UTC)Reply

If Changes when copying references from other pages is out of scope, then having a more unique reference name is even more important to me. So fallbacks like news-1 become unworkable, but if you can make a strong case that author, title and website parameters will offer reasonably unique usernames, I would be satisfied. The very simple solution would be to auto-increment from a semi-random 6-digit number, which would offer fewer hash collision like book-378293 and news-243390 along with the originally proposed Jane-Austin-Pride-and-Prejudice. Shushugah (talk) 23:01, 19 March 2026 (UTC)Reply

When copying a named reference to another article and there's a reference with the same name already, VisualEditor will add a number to the copied reference name. That's what's already happening both with the current auto-generated names as well as with any other names. We would keep that mechanism, but I believe that the content-based solution is good enough for such a scenario not to occur too often. But that obviously only applies to references using a template or a URL to derive the ref name from. The fallback – either our solution 1 (book-1, news-1 etc.) or the current names (:0, :1 etc.) – will of course still lead to scenarios where we need to increment the number when copying a reference to another article.
I'm not sure multiple references with different semi-random 6-digit numbers (book-378293, book-243390, book-181450...) make it easier for wikitext users to spot the reference they are looking for, compared to just remembering that "book-2" is the one they are currently interested in? Johannes Richter (WMDE) (talk) 07:23, 20 March 2026 (UTC)Reply
@Johannes Richter (WMDE) Currently when an editor in source mode copies <ref name="book-1" /> from Article A to Article B and that source already exists in Article B, it will incorrectly duplicate the sourcing. Whereas if there was a more unique reference number, a giant red-error would appear below (see below example) indicating to the editor that they copied an incomplete source. This happens frequently when editors are doing large scale cut/copy pasts or moves across articles. Shushugah (talk) 17:20, 21 March 2026 (UTC)Reply
@Shushugah I'm sorry if I didn't make that clear enough, I was talking about copying a named reference in VisualEditor. You are right that copying <ref name="book-1" /> in wikitext editor might lead to scenarios where users accidentally re-use a reference with the same name in article B instead of using the (different) reference from article A – that's an existing issue with <ref name=":0" /> as well. We believe that such a scenario should occur less often than it currently does, because many references will get meaningful, content-based reference names (and even the fallback provides multiple different names compared to the status quo), but the scenario you've described will still occur sometimes. --Johannes Richter (WMDE) (talk) 10:00, 23 March 2026 (UTC)Reply
I am happy with the content based naming solution you proposed but dissatisfied with the web-1, book-1, and other highly “common” name combinations in the cases where users use source mode, which is especially common with complex templates that don’t allow editing in visual mode. If your hypothesis is correct that they’re rare it should be a big deal. Even adding a YYYY-MM-DD would make it better because when trying to figure out where it was copy/pasted from, I could do a global search across Wiki and fix it by choosing the best matching citation. That would be a better solution than a random 6-digit hash too. Shushugah (talk) 11:58, 23 March 2026 (UTC)Reply
Names like book-378293 would not address/solve what's described in W17: Improve VE references' automatic names and reuse – W440: Unique and useful automatic reference names instead of ref name=":1" etc is clearer and broader so I prefer that one but I think that other wish was promoted more and thus is the one that got the votes where this info is not as visible: it does say If you read the article in source mode, you will not know which source is used. and A better system would be to automatically use the lastname_year or publisher_year if available, with sensible fallback options if unavailable. The ref-name should be somewhat informative about the source allowing the editor editing the wikitext to easily which source it is by just the name. It could also the title of the source trimmed to some max length. Prototyperspective (talk) 13:14, 23 March 2026 (UTC)Reply
Changes when copying references from other pages will be easier to handle correctly when the mw:Parsoid/Parser Unification is completed. WhatamIdoing (talk) 07:43, 30 March 2026 (UTC)Reply

A lot of the comments above assume that the ref will contain a citation template. For that matter, they assume that the ref will contain a citation to a source. This is not always true. For example, the English Wikivoyage has a handful of ref tags, but zero citation templates, and the contents are explanatory footnotes.

If there is a citation template, then I prefer a simple author-date format like ref name="Lee 2001", or even just the author name: ref name="Lee". When that is not possible, then a website name such as ref name="BBC" is an improvement – for me. Using the URL means using the Latin alphabet, and that might not be appreciated at wikis that use a different script. The original ref name=":0" approach was chosen specifically because it works on almost every keyboard.

But: What if there is no citation template and no URL? Would you pick a word from the contents, or continue with the old punctuation-and-number system? WhatamIdoing (talk) 07:27, 30 March 2026 (UTC)Reply

If a reference doesn't use a citation template and there's no URL, we would use our proposed solution 1 / 1.1. as a fallback (if the community agrees) or the status quo (if that's preferred by the community). Without a template that would either result in reference names like "reference-1" / "referencia-1" / "einzelnachweis-1" / "参考文献-" (depending on the wiki's language) or in another default name (if local communities define one according to solution 1.1.) or in the current ":0" ref name pattern. Johannes Richter (WMDE) (talk) 09:43, 30 March 2026 (UTC)Reply
My proposal would be: Use the first word after the first > as the name, if that's not convenient for some, they can just change it. The meaningless bloatword in front is just bloatware, and the current nonsolution isn't improved by that. Anything is better then :0, absolutely anything. Grüße vom Sänger ♫(Reden) 13:16, 31 March 2026 (UTC)Reply
It's not that simple: What if the word is a really long one (see the discussion above about maximum character length of ref names)? What if the first word ist just an initial (e.g. "J. Richter" would lead to ref name="J.")? Randomly picking some reference content can lead to lots of undesired results given that citation styles vary a lot across different wikis and different languages... And given that VE users won't even notice if their edit lead to an undesired ref name, they probably won't switch to wikitext to fix that (especially if they are inexperienced).
That's why we need a fallback which doesn't lead to potential new issues – that's either the status quo (":0") or the proposal 1 / 1.1. Johannes Richter (WMDE) (talk) 13:55, 31 March 2026 (UTC)Reply
We could build a list of exclusions (e.g., a, an, the, ein, eine, eines, einen, einem, der, die, das, den, dem, uno, una, unos, unas, el, la...). A minimum length alone is not a good answer, as there are a number of two-byte last names (e.g., Oh/오 and Li/李) and even a few single-byte names (e.g., w:Malcolm X). WhatamIdoing (talk) 20:08, 31 March 2026 (UTC)Reply

Dewiki users pointed out that the proposed fallback (solution 1 -> "reference-1") might lead to undesired auto-generated names when using references for explanatory notes. I'm not sure if it's that big of an issue?

If the note includes a URL, it's auto-name will be generated using the domain, if it includes a template which assigns the "note" cite class, the auto-name would be "note-1". But if the ref note just includes plain text, the auto-name according to proposal 1 would indeed be "reference-1". Given that most explanatory notes are probably created by wikitext users and rarely re-used by VisualEditor users, such auto-names don't seem very likely to occur (a quick search on enwiki for <ref name=":0" group="notes"> shows six articles, e.g. this VE edit). Johannes Richter (WMDE) (talk) 10:32, 13 April 2026 (UTC)Reply

It's unusual for an explanatory note to get re-used, so I would expect this to be uncommon. WhatamIdoing (talk) 16:44, 13 April 2026 (UTC)Reply