Template talk:R

Proposed new calling syntax

[Follow-up from : #Broken]

Regarding support for multiple citations, I see pros and cons both ways, therefore I'm undecided on this. Enumerated parameters don't confuse me, and those who are confused by them can easily avoid them and use the template for one citation only. Sure, the source code of the wrapper looks a bit convoluted, but it doesn't effect the subtemplate - this looks distracting because of the limitations of the Mediawiki template "language", not because we support multiples.

As far as I have investigated this, the overload was caused by a bug which pulled more or less whole articles instead of specific context sections only, not by the handling of many parameters. Utilization statistics are back to normal in the reported articles. There are many templates handling a similar amount of parameters, so, while it does not look nice, it is not really a problem we would have to act on now.

We might switch to Lua at a later stage, this would certainly make the code look much nicer. But I try to avoid it at this stage because it will dramatically reduce the number of people who can read it. It's still an option in the long run.

In general, it cannot harm to convert articles to use R for single references only, but I don't have the time for this gnomish work, and I don't want to put the burden on someone else at this point in time - if we don't remove support for multiples eventually, it might turn out to be a purely cosmetic change.

Alternatively, to cover the multiple citation cases we could also have something like {{r-m}} (as "rm" is already taken) or {{rr}} continuing to support the existing syntax for enumerated and unnamed parameters, so the switch would be a trivial change from {{r}} to {{rr}}. Once done, support for enumerated parameters could be removed from {{r}} and then the syntax for unnamed parameters could be used for better things:

• {{R|name}}
• {{R|name|page}}
• {{R|name|"quote"}} (for this, quotes would have to be given in quotation marks - at present we don't support the case of quotes without pages, because we could not show a tooltip for the quote, but in a future implementation it might make sense to support it, because the quote could also be appended to the citation using |a=q)
• {{R|name|"quote"|language and/or translation or "translation"}} (If we know that preceding parameter is a quote, one or two more optional unnamed parameters can be for the language of the quote and a translation. If the first of these optional parameters would be a language code, either because it is two-characters long or because it is known from a list of supported codes, the parameter can be assumed to hold a language code, otherwise it will contain a translation. If the parameter is given in quotes, we'd know it is a translation as well, so if there is another parameter following, it will be the language.)
• {{R|name|page|quote|...}} and {{R|name|page|"quote"|...}} (here the quotation marks are optional, because we have three parameters already - the optional fourth and fifth parameters would be for language and translation as in the example before)

If groups need to be taken into account, just add |g=group.

Additionally, we could detect a number of common or predefined group names unlikely to be names as well (like "notes", "lower-alpha", "nb", etc.) when given instead of names, and if found, also support the following (that is, insert the group name of these "known" groups at the first position and shift all the other parameters by one):

• {{R|group|name}}
• {{R|group|name|page}}
• {{R|group|name|"quote"}}
• {{R|group|name|page|quote}} and {{R|group|name|page|"quote"}}

This would also include the empty group to support this syntax variant as well:

• {{R||name}}
• {{R||name|page}}
• {{R||name|"quote"}}
• {{R||name|page|quote}} and {{R||name|page|"quote"}}

For the remaining other group names, it would always be possible to use named parameters like |g=group. (In these example I skipped the language and translation parameters for brevity, however, the same logic as described earlier would apply here as well.)

Changing from invocation to definition, one would only have to add a named parameter |r=/|reference= to the set. And to append to a definition elsewhere use |a=/|annotation= instead.

Of course, it would also be possible to keep the syntax for {{r}} as it is and create the suggested new syntax under a new name. However, I consider the name "r" to be spot on for a template this flexible (and therefore also important for its success), therefore, if we would change the calling syntax for unnamed parameters, we should move the old unnamed syntax (and thereby also enumerated parameters to support multiple citations) to a new wrapper template like the suggested {{rr}}. --Matthiaspaul (talk) 12:01, 1 September 2021 (UTC) (updated 10:04, 4 September 2021 (UTC))

{{r}} meanwhile also allows to group sub-references (like short references) under their full citation (this looks quite similar to what the meanwhile cancelled WMDE Book Referencing extension should have accomplished). There are various ways how to set this up, but while quite simple already, they all still require editors to fiddle around with link anchors. I'm planning to build on and further simplify the user interface for this, thereby also reducing redundancy among parameter values. I'm not completely sure about this yet, but in this process, it might be possible to integrate the functionality of {{rma}}/{{ran}} for named links in an intuitive way as well.

Further extending my proposed new calling syntax above:

{{R|page/pages/at=page/pages/in-source-location}}

That is, giving no name, but one of the page/pages/at (or aliases) parameter, the template could be made to work identical to {{rp}} (except for the {{rp|unnamed parameter}} case, because (per the proposal above) for {{r}} the first unnamed parameter should be reserved for the name (or group), not a page number, and we have no way to distinguish between them).

{{R}}

Finally, giving no name, none of the various page parameters, and neither |r(eference)= nor |a(nnotation)= (and, if any, only parameters from a selected set of special parameters), {{r}} could be made to work like {{reflist}}.

This way, a future version of {{r}} could handle the whole ecosystem of r-style full and shortened referencing, including inline and list-defined referencing, through one template with one logically stringent and intuitive parameter interface (in contrast to the harv-style shortened referencing system, which requires a huge amount of specialized templates to handle all the corner-cases), and at the same time allow combined use with any of the other referencing systems. Being able to "just think r" to do anything related with referencing seems quite convincing and would hopefully help to gain more acceptance among users.

But before we could introduce this new calling syntax, we would have to move all existing uses of {{r}} to {{rr}}, which would continue to support the current calling syntax (with support for multiple citations in one) into the future. Once all existing uses would have switched to {{rr}}, we would be free to change {{r}} to use the new calling syntax and adjust the wrapper {{rr}} accordingly so that backward compatibility would not be broken (at present, with both templates still using the same syntax, {{rr}} is just a redirect to {{r}}).

So, if you, EE, want to take care of switching over existing uses to {{rr}} (possibly assisted by a bot), please do.

--Matthiaspaul (talk) 18:57, 16 September 2021 (UTC)

Sorry, I don't understand what all the stuff about groups has to do with this. I'm going to call on my old pal Wugapodes, who I've already burdened elsewhere, to ask if he can do something. Wugapodes, it's this: I'd like a list of all articles that have at least one invocation of {r} in which at least one of the parameters |2= |3= ... |9= is nonempty (whether via unnamed parameters e.g. {{r|foo|bar}} or explicitly {{r|foo|2=bar}}). Can you script something to do that? If you can spit out the actual qualifying invocations, or a count of the number of qualifying invocations are in each article, that would be great if they're easy, but a simple list of articles having one or more would be quite satisfactory. EEng 05:18, 17 September 2021 (UTC)

Don't worry about the groups. We are just looking at it from different angles. For you the incentive for a new syntax was that you found support for multiple citations to be handled by one call confusing, for me the incentive to change the syntax came when I realized that the user interface could be improved by making better use of unnamed parameters (hence my examples of the quite many common combinations we could decode reliably already without having to use named parameters).

In theory, as {{rr}} will continue to support the current syntax, someone could blindly run a script changing all existing calls to {{r}} into {{rr}} without changing any parameters, but, as you write, actually necessary to address would be only those calls which use either more than one unnamed parameter, or any kind of enumerated named parameters.

--Matthiaspaul (talk) 10:05, 20 September 2021 (UTC)

I like the idea of a new syntax, but I kind of want to argue that Lua makes it more readable by making things more structured. I guess my "readable" just means code readability, i.e.look[ing] much nicer. I don't know much about how many people are able to read nested Wikitext vs "straightforward" Lua; I always assumed that it's about the same. Artoria2e5 🌉 07:09, 30 December 2023 (UTC)

Template-protected edit request on 4 November 2023

Remove   as a space before the colon is a French convention. Santiago Claudio (talk) 08:59, 4 November 2023 (UTC)

 Already done by Paine Ellsworth. * Pppery * _{it has begun...} 17:18, 5 November 2023 (UTC)

Space before colon in pop-up

Resolved

In what template is that? To any proper user, kindly remove that non-breaking space. Santiago Claudio (talk) 08:21, 6 November 2023 (UTC)

Please link to a page where we can see the problem. – Jonesey95 (talk) 18:39, 6 November 2023 (UTC)

@Jonesey95: This page, Template:R/doc, has examples of underlined pages. Santiago Claudio (talk) 02:27, 7 November 2023 (UTC)

I see page numbers with dashed underlines, but I do not see any nbsp characters when I expand the code that renders page numbers like that. Maybe provide an example here, or say specifically what you are seeing. None of us here can read your mind. – Jonesey95 (talk) 15:14, 7 November 2023 (UTC)

"Quotation :" instead of "Quotation:". Santiago Claudio (talk) 00:00, 8 November 2023 (UTC)

I am unable to find that string on {{R/doc}}. – Jonesey95 (talk) 01:07, 8 November 2023 (UTC)

Who's on first? EEng 01:54, 8 November 2023 (UTC)

I don't know. – Jonesey95 (talk) 01:59, 8 November 2023 (UTC)

Hover over underlined pages in R/doc § Inline invocation. Santiago Claudio (talk) 09:15, 8 November 2023 (UTC)

I see it now. The space in "Quotation :" appears to come from {{R/superscript}}. It's actually an unintentional new line, which is probably coming from one of the modules used inside that template. Also, when |language= is used, there is no space: "Quotation(Spanish):". That also could be fixed. I asked for help at WP:VPT. – Jonesey95 (talk) 15:12, 8 November 2023 (UTC)

@Jonesey95: I think I've managed to fix both of the bugs you describe with this change on the sandbox - does this look fine (I'm not familiar with this template)? I managed to fix the magically appearing newline by making the : its encoded version instead - I suspect there's some weird logic going on here with it being the first character in the string (hence why the bug only happens when language isn't given) leading to some sort of parsing behaviour, but I'm clueless on what the exact chain of events could be that causes that. Aidan9382 _(talk) 15:56, 8 November 2023 (UTC)

Thanks! I always forget about Help:Template#Problems and workarounds. The parser sometimes interprets an in-line colon as the beginning of a new, indented line, as in the colons at the beginning of this line. I have copied the sandbox code to the live template, and it works well. I also added an example to the documentation using |language=. – Jonesey95 (talk) 15:59, 8 November 2023 (UTC)

Many thanks to you both, Aidan9382 and Jonesey95! Santiago Claudio (talk) 03:20, 9 November 2023 (UTC)

Cannot do |r= and |a=: at the same time

I am struggling to find a way to both define a citation with {{{r}}} and a sub-annotation with {{{a}}}. Here's what I've tried:

{{r|n=FAO92|r={{cite book |title=Maize in human nutrition |date=1992 |publisher=Food and Agriculture Organization of the United Nations |location=Rome |isbn=9789251030134}}|loc=§5.2|annotation=#[[#L1|^]] §5.2 [https://www.fao.org/3/T0395E/T0395E07.htm Lime-treated maize (part II)]|link-id=L1}}

And here is what I get:

The annotation makes it through unscathed, but the {{{r}}} just turns to blank. Is there a workaround somehow? Like, some sort of way to call {{r|n=FAO92|r={{cite book |title=Maize in human nutrition |date=1992 |publisher=Food and Agriculture Organization of the United Nations |location=Rome |isbn=9789251030134}}}} beforehand, invisibly? Artoria2e5 🌉 14:06, 31 December 2023 (UTC)

I looked at the code in {{R/ref}}, and as far as I can tell, it is intended to render either an annotation or a reference, but not both at the same time. There is an #if test for |annotation= that explicitly does nothing if the parameter has a value; if the parameter is empty or missing, a normal reference is rendered. I think the code would need to be refactored to do what is requested above. – Jonesey95 (talk) 15:05, 31 December 2023 (UTC)

Hmmm. I would really want this feature to be a thing; right now I don't see any chance for obvious errors since I am explicitly specifying |a= and |r=. Artoria2e5 🌉 09:00, 12 February 2024 (UTC)

The current workaround is to use {{nodisplay-span}} to make an invisible r-only invocation before any |annotation= invocation is done. --Artoria2e5 🌉 09:10, 12 February 2024 (UTC)

This abomination needs to go

It plays very badly with visual editor and with various tools. For example, I wanted to reformat (convert) citations (missing dates, authors) etc. in Maciej Wąsik. Impossible. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:55, 17 January 2024 (UTC)

Why is it impossible? EEng 05:40, 17 January 2024 (UTC)

@EEng What I meant is that it is impossible to edit references using this template in the Visual Editor (or, if it is possibloe, I'd like to know how to do it). Right now I can either manually and painstakingly try to convert references to visual editor compatibile simple format in code, or give up on trying to edit the references using that system. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:26, 17 January 2024 (UTC)

I looked at the article, and the only thing I can imagine you're having trouble with is WP:List-defined references, and those aren't specific to {r}. EEng 17:37, 17 January 2024 (UTC)

Visual Editor is very limited when it comes to interacting with list-defined references, according to this help page and Wikipedia:VisualEditor#Limitations. – Jonesey95 (talk) 14:16, 18 January 2024 (UTC)

Those two seem to often be used together. Since VE is the default tool for new editors (and anyone who is not particularly masochistic), we really should think about how to fix this (of course, coding this into VE shouldn't be impossible...). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:29, 19 January 2024 (UTC)

I agree that VE ought to be fixed. This is, like, Problem #482 with it. EEng 02:26, 19 January 2024 (UTC)

I'm a big fan of VE, but I don't think incompatibility is a good reason to say people shouldn't use this referencing system. How about asking at the article talk page if anyone would care if you converted to a different referencing system? Mike Christie (talk - contribs - library) 17:38, 19 January 2024 (UTC)

@Mike Christie Converting is a lot of work, and I do not care much about that article. But what I worry is that increasingly, most people rely on VE, and so articles that use this legacy code are becoming increasingly difficult to fix. I mean, I am a veteran editor, I could fix this article, I don't want to - it is too much hassle (if it used VE compatible code, it would take me one minute, fine; converting would take me 5-20 minutes - no, I am not willing to do this as this is effectively make-up work that should be done with some gadget/button). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:59, 20 January 2024 (UTC)

That's fair. It might actually be possible to have a bot change it from LDR; if there's no disagreement on the talk page. I don't think any such bot exists but it's an idea. Mike Christie (talk - contribs - library) 02:13, 20 January 2024 (UTC)

While this needs a VP/RFC, maybe we should have a bot do it for all articles? I don't see what benefits the legacy system has, while the disadvantages (making things hard to fix for VE users, i.e. 99.9% of the new users and growing number of old ones) is clear. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:50, 20 January 2024 (UTC)

This problem seems like a problem with the just-recently-out-of-beta Visual Editor, not with LDR, but maybe I misunderstand. It seems like the VisualEditor tail is wagging the dog, but if there are other reasons to object to LDR, maybe that style should be re-evaluated. – Jonesey95 (talk) 05:30, 20 January 2024 (UTC)

It looks like it should be pretty easy to automate. I'll see if I can put something together in the next day or so to try out on this article. Re the tail wagging the dog: it would be inappropriate to do mass updates unless as Piotrus suggests LDR get deprecated, but a tool to switch easily when there is consensus to do so seems harmless. Mike Christie (talk - contribs - library) 09:31, 20 January 2024 (UTC)

The title of the thread is correct. If this abomination, VE, cannot handle list-defined references, then VE needs to go. If it cannot handle list-defined references, it also cannot handle repeated references, and those are unavoidable. On the other hand, R is just fine for repeated references or other uses of labeled references such as list-defined references, and does not need to go anywhere.

As for deprecating list-defined references, I would strongly oppose any such change. Having the references interrupting the body text makes it very very difficult to read the source text for those of us not using this abomination, VE. List-defined references fix that by putting all the references in one convenient place where they can be cleaned up if you are cleaning up references or ignored if you are editing body text. And for long articles with many repeated references, list-defined references make it much easier to find the reference than having them inline somewhere far away in the source. As someone said above, using this abomination VE as an excuse to prevent us from using list-defined references would be the tail wagging the dog. —David Eppstein (talk) 18:07, 22 January 2024 (UTC)

Piotrus, I have created a script that converts pages written using {{R}} to use named references instead. I've tested it on Maciej Wąsik; you can see the converted version here. Can you take a look and see if you can find any problems with the conversion?

It would be fairly easy to change the script to convert in the other direction -- that is, it could take a page using named references and convert it to list-defined references using R.

I think there's a potential for misuse of this script (in contravention of WP:CITEVAR) so I probably should not make it generally available, but if there are pages using LDR and you get no opposition on the talk page to changing the citation style, I can try applying the script. I've only tested it on this one page so far and no doubt there are special cases I haven't considered, so it might not work in all cases. Mike Christie (talk - contribs - library) 22:51, 29 January 2024 (UTC)

I for one would strongly object to uses of this script to un-list-define any article I have drafted in list-defined format. And your script conflates two different things: whether the references are list-defined, and whether named references defined elsewhere (regardless of whether elsewhere in the body or elsewhere in a list of refs) are accessed using {{r}} or using <ref name=name/>. But I think your script is buggy: it has not converted all the {{r}} templates, and as a result it is not true that all references have been moved up to the point of their first use. In your example link, references gov.2023 and gov.briefing have both been moved up to their second use, with the first use left unconverted. —David Eppstein (talk) 23:47, 29 January 2024 (UTC)

Yes, I wouldn't apply it unless I saw agreement from editors of that page to do so, or the relevant editors had retired. Thanks for pointing out the bugs -- will have a look at those. There may be no demand for this anyway, but it was an interesting exercise. Mike Christie (talk - contribs - library) 23:54, 29 January 2024 (UTC)

That bug is now fixed, though no doubt there are more limitations. Mike Christie (talk - contribs - library) 03:14, 30 January 2024 (UTC)

@Mike Christie Thanks for the tool. Can you adjust it so it does not move the references to the infobox if possible? VE cannot handle references hidden in templates.

In other news, it is ridcolous VE still cannot do it. Anyone knows which bugzilla tracks this? WMF has money to give away to unrelated projects by other NGOs but not for finishing VE. Ridcolous. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:16, 2 February 2024 (UTC)

It would be possible to move the refs out of the inbox with a script, but I think that should be a separate function -- I'd rather not combine it with this. In some cases it wouldn't work anyway as the only instance of a reference might be within the infobox. And I think it's more general than just infoboxes; if a ref tag only occurs within a note tag I think those are also invisible to VE. There are certainly Phab reports on the issue; if I recall correctly it's a bigger development effort than it appears. WhatamIdoing, do you recall the status on this? I know you've been repeatedly asked about this over the years and I thought you might have the inside information. Mike Christie (talk - contribs - library) 02:26, 2 February 2024 (UTC)

It seems likely to me that the same thing that prevents VE from seeing references in iboxes is the thing that prevents it from seeing them in reflists. See my earlier comments about "this abomination, VE": we should not let its limitations push us into worsening editing for the rest of us who avoid it, by making the source code of our articles unreadable. —David Eppstein (talk) 03:08, 2 February 2024 (UTC)

Mike, it's called "rich editing of templates", and it is a h-u-g-e project. I believe that it's currently blocked on the parser unification (and, you know, deciding to have a development team spend a couple of years on it instead of, say, the mobile visual editor).

@Piotrus, if this particular template (Template:R) is the same as the one used years ago at the Polish Wikipedia, then @Tar Lócesilion will know what's involved in converting. WhatamIdoing (talk) 07:13, 2 February 2024 (UTC)

If the issues are what I think they are, then {{r}} is not the problem. The problem is VE + list-defined references and you would have exactly the same problem regardless of whether you used {{r}} or <ref name=X/> to access those list-defined references. You could test this by trying to use VE to edit a named reference defined elsewhere in the body (not list-defined) and comparing its behavior for {{r}} vs <ref name=X/>. —David Eppstein (talk) 07:21, 2 February 2024 (UTC)

I finally filed a bug at phabricator about the VisualEditor and list-defined references here: https://phabricator.wikimedia.org/T356471

As the help page linked above says: "You can edit existing list-defined references in VisualEditor. You cannot add or remove list-defined references. It also does not support modifying list-defined references inside {{reflist}}, only <references/>."

The VisualEditor struggles with the {{r}} template's named references because they are defined within a template. If named references are defined like <ref name="Doe1999">Doe, John (1999). ''Some Book''.</ref> within the body text, then the VisualEditor does fine. If you ever come across pages with reference names like ":2" those are the default names created when the VisualEditor creates named references. Hope that helps, Rjjⁱⁱⁱ (talk) 03:58, 9 February 2024 (UTC)

It is not actually a necessary part of using {{r}} that its references be defined within a template. They could be defined as above within body text. Or you could wrap them inside <references> ... </references> at the end of the article instead of using the {{reflist}} template to do that for you. Maybe it is {{reflist}} that we should be pushing to eliminate in favor of <references> so that VE works better? Only now I see in the phab bug and its test case that this abomination VE does not even work with list-defined references using <references>. —David Eppstein (talk) 05:57, 9 February 2024 (UTC)

Should I use {{r}} or <ref>?

I was reading the article about Swatting and I discovered an {{r}} reference named "Krebs_1" with a page number and a tool tip. This was my first time seeing that. I thought there was an error with the reference, so I looked at the source and noticed that there was a quote but when I hovered over the reference, the quote did not show. It did not occur to me to hover over the page number to see the quote in the tool tip. I also noticed that this quote did not display in the references section like a <ref> quote does so I could not read it there either. The only place to read the quote was hovering over the page number, which in this case was unnecessary because the reference was a single short web page and not a book with multiple pages. Maybe I shouldn't have but I changed the reference to the <ref> format and moved it from the references section. I changed the format of the reference so that the quote would be appended to the citation instead of displayed as a tool tip. It may have been an unnecessary edit but I worry that other Wikipedia readers might not understand that if you hover over the page number there might be a tool tip. This was not at all obvious to me.

Also, the tool tip text is much smaller and more difficult to read than the text in the citation.

So, the main reason I am creating this topic is to find out which reference system I should use when working with references? Most of the edits that I do are fixing dead links and adding archived pages and in general fixing references as I read Wikipedia. For my future edits would it be preferred to use the {{r}} template format or the <ref> format or does it matter? Also, on my first edit of the Swatting page in the references section, I removed {{reflist}} and replaced it with <references /> after I moved the reference out of the references section. However, I was unsure of the differences between {{reflist}} and <references /> so I changed it back. What is the difference? I noticed that there was another {{r}} reference in the source and it still displayed correctly in the references section when I used <references /> instead. Also, I don't use an editor, I edit the source directly. -- Ubh [talk... contribs...] 15:03, 7 March 2024 (UTC)

The {{reflist}} template permits overriding the defaults on <references />, but if you're not using those parameters it's supposed to be identical. I believe there is a slight difference in rendering on mobile. It also used to be the case that using <references /> was better for editors using the Visual Editor, but VE now copes with {{reflist}} so that's no longer an issue. I typically use <references />. For {{r}} vs. <ref> tags, as a VE user myself I find the ref tags much easier to work with, and as {{r}} is not widely used I would not suggest you adopt it unless it has some specific benefits you like. If you're editing an article that has an established citation style, though, you should try to stick with that, per WP:CITEVAR. Otherwise if you use VE it will put in ref tags by default. If you don't use VE, I would suggest using whatever you find easiest -- ref tags, {{sfn}}, or one of the other systems out there. Mike Christie (talk - contribs - library) 15:57, 7 March 2024 (UTC)