Template talk:R/Archive 1

Archive 1

Tools

Resolved

I like this, as it does simplify the markup, but it is going to render good tools like redToosl and checklinks useless. ---— Gadget850 (Ed) ^talk 18:08, 22 September 2009 (UTC)

Hello Gadget850. Most tools that handle references shouldn't be affected by the template, since the references are simply moved into the References section (see example diff). Checklinks shouldn't be affected at all. RefToolbar should still work fine, although it will add <ref> tags instead of {{r}}; I could help add support for it if Mr.Z-man doesn't have time to. —{admin} Pathoschild 18:36:51, 22 September 2009 (UTC)

Oh— the template is not at issue, it is the list-defined references. I think I may have found an LDR bug. Gotta work on this. ---— Gadget850 (Ed) ^talk 18:55, 22 September 2009 (UTC)

Still trying to figure out why Checklinks works with some article, but not others, but it is not this templates. ---— Gadget850 (Ed) ^talk 14:48, 23 September 2009 (UTC)

Incorporating the functions of Template:rp

I edited the template to allow parameters rp1 through rp5, to insert {{rp}}'s functionality directly into this template. I also updated the documentation. Let me know if this breaks anything, but so far, I can't see anything wrong. (Incidentally, I think you should be able to pass {{rp}}'s named parameters using a {{!}} (fake pipe).) TheFeds 03:55, 23 September 2009 (UTC)

Hello TheFeds. Do you have any objections to a more self-evident parameter name, like page1 instead of rp1? (I don't think we should encourage using {{!}} in articles to bypass syntax, since it's rather counterproductive to the aim of simplifying article code.) —{admin} Pathoschild 04:59:19, 23 September 2009 (UTC)

Just to clarify the intended usage of {{!}}, say you want to do something like {{rp|needed=y|date=September 2009}} within an instance of {{r}}. You'd code that as {{r|Reference1|rp1=needed=y{{!}}date=September 2009}}. Except that I just realized that this doesn't work—the template code feeds everything to {{rp}}'s {{{1}}}, rather than its raw input string.

As for the parameter names, I didn't want to use the obvious (page, pages), because {{rp}} already uses those parameter names to do AMA style (it parenthesizes the value). I figured that a user of {{rp}} would not like the confusion of the "page" parameter working differently in this template. So, I settled upon the name rp# (in lieu of the unnamed first parameter of {{rp}}). I don't think that the name is a problem, all things considered. TheFeds 06:56, 23 September 2009 (UTC)

rp adds page numbers with a colon, page adds them with parentheses? That's not very intuitive. I think it's preferable to have a meaningful syntax than to be similar to {{rp}}'s syntax, such as page1 and page1_ama. This makes the template more readable for all editors, and is very simple for editors used to {{rp}}.. —{admin} Pathoschild 14:16:16, 23 September 2009 (UTC)

{{Rp}}'s parameters are a bit weird, but I think that's because the AMA style is used quite rarely on Wikipedia. Most users want the standard behaviour (with a colon), so they never even pass named parameters to {{rp}}. We can't use an unnamed parameter here (as {{rp}} does), so I think calling it rp1 is a decent way of implying that the output will be the same as using {{rp}}'s 1st, unnamed parameter. In other words, I'd rather imply to the user that this template is invoking {{rp}}, rather than make it seem like it's using its own parameter names to do the same thing. TheFeds 17:24, 23 September 2009 (UTC)

I don't think the parameter names should depend on editors knowing which templates are used internally— I didn't know about {{rp}} until yesterday, so an rp1 parameter would have been meaningless to me until then. We're not even likely to continue using {{rp}} internally, since it would be more efficient to have similar code in this template without the extra programming for {{rp}}'s extra parameters.

It would be better to reach a consensus, but we can compromise by simply recognizing both. How about recommending page in the documentation, and recognizing rp as an alias for editors used to {{rp}}? —{admin} Pathoschild 17:53:29, 23 September 2009 (UTC)

Done. I'd still prefer to remove rp* entirely, if we can agree to do so. —{admin} Pathoschild 01:47:36, 25 September 2009 (UTC)

I'd be alright with dropping the rp# syntax...it's definitely more obvious in general to use page#, as long as you don't care about AMA style. (And most editors probably don't, despite the fact that {{rp}} supports it.) You're probably right that it's better to make this template clear, than to support the {{rp}} feature set directly.

It wouldn't be to hard to code something that said if AMA=yes, do the AMA thing with parentheses, else default to the usual style. Of course, I don't know if there's enough demand for this to support AMA in the first place.

By the way, as long as page# in {{r}} acts differently than page and pages in {{rp}}, there's no point in trying to maintain the same behaviour—because that's already divergent. TheFeds 18:20, 25 September 2009 (UTC)

Documentation

"This should be avoided whenever possible, since it reduces prose readability; page numbers can often be specified in the reference itself."

That reads like a guideline: what is the source? ---— Gadget850 (Ed) ^talk 03:10, 25 September 2009 (UTC)

I copied it from {{rp}}'s documentation, the original source of the functionality. Quote for future reference:

This template should not be used unless necessary. In the vast majority of cases, citing page numbers in the <ref ...>...</ref> code is just fine. This template is only intended for sources that are used many, many times in the same article, to such an extent that normal citation would produce a useless line in <references /> or too many individual ones. Overuse of this template will make prose harder to read, and is likely to be reverted by other editors. Used judiciously, however, it is much less interruptive to the visual flow than full Harvard referencing and some other reference citation styles.

—{admin} Pathoschild 03:52:12, 25 September 2009 (UTC)

Group

Need a group parameter to include full functionality. ---— Gadget850 (Ed) ^talk 11:41, 23 September 2009 (UTC)

Done. {{r|foo|bar|group=baz}} will reference foo and bar in the baz group. —{admin} Pathoschild 14:29:53, 23 September 2009 (UTC)

Works nicely. Thanks. ---— Gadget850 (Ed) ^talk 14:47, 23 September 2009 (UTC)

Maximum of 5 consecutive references

Is there any specific reason why this template can only handle 5 consecutive references? I try to use this template for references as much as possible (and even built a "bot" to automatically convert an article to using LDR and R). But the problem is mostly on music articles that contain tons of genre references (sometimes up to 7 or 8 for one genre). Is there any reason why the max can't be any higher than 5? I'll even go in myself and add its ability if there isn't something more serious that will happen if the template allows for more reference calls. =) ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 11:38, 4 December 2011 (UTC)

Cancel that. The very error message that led me here invites the user to "edit it!". And so I did.  Done Template now allows 9 references (just for retaining a nice one-digit number. ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 04:18, 5 December 2011 (UTC)

Village pump

This template is generating some discussion at the village pump. It's probably of interest to anyone who is watching this page. GyroMagician (talk) 11:29, 2 February 2010 (UTC)

TfD

This template is under discussion at Wikipedia:Templates for discussion#Template:R. Per the guidance at Template:Tfd-inline: "where the insertion of either template is deemed too detrimental to a large number of articles, it might be advisable to place the notice on the template's talk page instead." ---— Gadget850 (Ed) ^talk 23:22, 17 February 2010 (UTC)

I've added it to the top of this page. SlimVirgin ^{TALK contribs} 23:27, 17 February 2010 (UTC)

Ah. The wording on the TfD template could use some work. ---— Gadget850 (Ed) ^talk 23:48, 17 February 2010 (UTC)

I agree that the TfD warning is very intrusive (I was one of the first to complain!) but the alternative seems equally unhelpful. A message placed at the top of this page is unlikely to be seen by many (any?) of the editors using this template. The first they are likely to know is when the template is deleted. What we really need is abanner at the top of each affected page, but I have no idea how to achieve that. Any ideas? GyroMagician (talk) 23:54, 17 February 2010 (UTC)

This issue should be discussed at Template talk:Tfd-inline. ---— Gadget850 (Ed) ^talk 03:52, 18 February 2010 (UTC)

TfD again

See why at Talk:Chelicerata#I_no_longer_maintain_this_article --Philcha (talk) 05:12, 10 July 2010 (UTC)

Please see WP:TFD for information on opening a TfD. I removed the TfD notice, feel free to add it back once a case has been opened. ---— Gadget850 (Ed) ^talk 11:02, 10 July 2010 (UTC)

Could you please explain "add it back once a case has been opened" - as far as I can seen, WP:TFD does not use the word "case". --Philcha (talk) 11:36, 10 July 2010 (UTC)

Listing, case, ticket, file, docket... whatever. See Wikipedia:Templates for discussion#Listing a template. You did step I, but not II or III. Please add a complete rationale and don't just link to that talk page. ---— Gadget850 (Ed) ^talk 14:26, 10 July 2010 (UTC)

[1] {{r}} has caused a lots of trouble. An RfC was proposed on 1 February 2010, I can't find the conclusion but it overwhelming suported the RfC, e.g. rejected {{r}}. I'm not wasting any more time on this. --Philcha (talk) 20:18, 10 July 2010 (UTC)

I'm sorry I missed the TfD for Template:R. Here are my two replies to the biggest issues raised, as well as some additional examples of why and how I use it:

1. As previously discussed, it does save a bit of space and eye-strain in large articles. In Lemur, for instance, it saves 4 Kb (157 Kb vs. 161 Kb the last time someone switched it). There's a big difference between reading: <ref name="Ref1"/><ref name="Ref2"/><ref name="Ref3"/><ref name="Ref4"/><ref name="Ref5"/> and {{r|Ref1|Ref2|Ref3|Ref4|Ref5}}. I should also note that I do not use the page numbers feature—I do not have any interest in it, nor would I support keeping that feature... unless I saw a good argument in favor of keeping it.
2. If you want to claim that {{R}} is harmful because it makes adding references harder, then you can also make the same claim with LDR (list-defined references). To be honest with you, when I first started on Wiki, none of the articles I wanted to edit had a common referencing theme, and to my novice eyes, the documentation pages I found were far from helpful or informative (in 2008). I was self-taught by learning from examples on articles I liked. I noticed some articles have references hand-typed between ref tags, other used {{Cite}}, and other did the bad thing by not using in-line references. To address this, as I slowly work to re-write and standardize the lemur articles, I have added detailed notes and links to a large comment in the reference section of each article I take up and through FAC. Admittedly, a new editor will be confused by the use of LDR and {{R}}, but at least there is a brief explanation, consistency within and between articles I've written, and provided links to work off of. I've also added {{Maintained|{{user|Visionholder}} to the talk page to encourage people to contact me about the references and any other issue with the articles.

Yes, my use of LDR may differ slightly from what was intended since I name each and every one of my refs. But there is a reason for that. Lately, I have been working with large articles (e.g. Lemur, Subfossil lemur, Lemur evolutionary history, etc.) and keeping references organized is very important. I can't even begin to count the number of articles I've encountered, large or small, where references were duplicated two, three, or even four times, and obviously by different editors because different reference styles and format were used. As I organize my articles, I use LDR to keep all references together and I use the names to help keep them organized. That's why I typically name my refs in the format "YEAR AUTHOR" (e.g. "1997Godfrey"). I also tend to organize refs by journal, book, and web/other. Admittedly, if you look at the editing view of Lemur, I don't explain the organization in the References section, but I will when I've had enough time to work out all the kinks and managed to standardize most of the lemur articles. Like the rest of Wiki, the lemur articles are still very much a work in progress... even the FAs among them.

Could I live without {{R}}? Yes. It's not essential. But at this point, I don't see the point to this debate. I read the TfD for deleting the template, and didn't see any good reason for deleting this specific template. All the arguments against could be used against most of the reference templates and standards (confusing, unnecessary, redundant, etc.). I realize that people have strong preferences for how they do their references, sometimes based on literary standards, other times based on personal preferences. So far, that seems to be what this debate is about. Until someone can provide a better reason for deleting {{R}}, I would oppose it. I'm sorry, Philcha. – VisionHolder « talk » 23:37, 11 July 2010 (UTC)

Sorry, I just read another another discussion listing your concerns. Again, the argument is a bit old, but since some comments received no reply, I figured I would try to address your concerns. – VisionHolder « talk » 20:59, 12 July 2010 (UTC)

1) Citation formatters such as refTool would create a mix of <ref> and {{r}} citations.

I have not used refTool. However, I personally prefer to use {{r}} with LDR, which I doubt refTool supports either. If it does, then <ref> tags are still used, but in the References section, not in the body. It would be a moot point in this case. Also, I feel that has Wiki evolves, tools can be updated as needed. I realize that may not be a satisfactory answer, but for me, neither is the argument that "things can't change because it would break what we have in place." – VisionHolder « talk » 20:59, 12 July 2010 (UTC)

2) Edit box tools such as User:Cacycle/wikEd don't display it properly.

Again, why can't the tool be fixed? These tools manage to differentiate {{citation}} from {{cite journal}} from {{cite book}}, etc. I realize that macros can proliferate, and bots and other tools shouldn't have to grow to accommodate them all, but I still feel that until Wikimedia comes up with a better, built-in referencing system, {{r}} is generally useful, especially for people using LDR and should be simple enough to accommodate. – VisionHolder « talk » 20:59, 12 July 2010 (UTC)

3) {{r}} should be suspended until the bots that maintain citations have been tested with it.

I'm fine with that.... BUT... is there such a testing method in place and will someone actually do it, or is this just another way to table a template indefinitely? As for bots working correctly, they already muck up citations (using <ref>, not {{r}}) in the References section of the lemur articles I write. Did all the citation templates pass the same criteria? If so, suggest a new round of testing. – VisionHolder « talk » 20:59, 12 July 2010 (UTC)

Now I realize that you have grown frustrated with editors slapping references with {{r}} into articles using <ref>. I completely agree with you there! For example, User:Ucucha and I review and collaborate with each other quite often, and he prefers to manually type his citations within <ref> tags and doesn't touch most templates, including {{cite}}. I now tend to LDR with {{Harvnb}} and {{r}} (with <ref> in the References section). I would not edit one of Ucucha's articles and start slapping in {{cite}} tags for a new reference. Instead, I follow his citation style. Likewise, he respects my citation style as well. I feel this is good etiquette. Is it confusing? Yes... but so is the difference between using <ref> and {{citation}} vs. <ref> and {{cite journal}} vs. <ref> and manual citations vs. LDR/{{Harvnb}}/{{r}}, etc., etc. We can't argue about standards when there are none. – VisionHolder « talk » 20:59, 12 July 2010 (UTC)

another format of indicating pages

Is there any other way of showing which page(s) I refer to (than this with^[1]:153-156)? I mean, that's not so pretty (although it's very good!). Can it be done like^[1] and the page number situated down at references?:

^ ^{a(153-156) b c} A Book of something.

This would be a lot clearer in the article. I'm asking mostly because of Polish Wikipedia, where I'm trying to do this. Vinne2 (talk) 13:22, 9 December 2010 (UTC)

No— that would have to be added to the Cite software extension. See T15127 - Page number attribute for ref tags. ---— Gadget850 (Ed) ^talk 15:53, 9 December 2010 (UTC)

You can either type out the ref manually, or use {{harv}}, which supports page numbers, etc. Gary King (talk · scripts) 18:46, 9 December 2010 (UTC)

Now I see... So we have to wait, yes...? P.S. Well, the {{harv}} takes too much space and it's text is big. I think smaller is better. I mean the <sup>. Vinne2 (talk) 23:02, 9 December 2010 (UTC)

Just wrap it in <ref></ref> tags to get the same thing as {{r}}. Gary King (talk · scripts) 00:20, 10 December 2010 (UTC)

He wants to include the page number in the backlink label— that cannot be done in the current version of cite.php. ---— Gadget850 (Ed) ^talk 04:47, 10 December 2010 (UTC)

That's exactly what I asked for q:D Vinne2 (talk) 10:16, 10 December 2010 (UTC)

If you create a Bugzilla account, you can comment on T15127. You might want to do this, as I haven't seen a concrete example of how the page number should appear. I am not enthused about your proposal, but you can give it a shot. ---— Gadget850 (Ed) ^talk 15:09, 10 December 2010 (UTC)

Simplify?

Is there a reason that the parameter page= has to be spelled out? Wouldn't it be easier to eliminate the label and just pipe the page number, as:

{{r|foo|15}} to render as ^[1]:15

Additionally, the page= could then be utilized as it is in {{rp}}, to put the page number(s) in parentheses, rather than after a colon:

{{r|foo|page=15}} to render as ^[1](p15) and

{{r|foo|pages=15, 30}} to render as ^{[1](pp15, 30)}

It might also be nice to reduce page= to p= and pages= to pp=

{{r|foo|p=15}} to render as ^[1](p15) and

{{r|foo|pp=15, 30}} to render as ^{[1](pp15, 30)}

Just thinking about further reducing the clutter/size of articles. Thanks!—D'Ranged 1 VT^alk 11:38, 23 February 2016 (UTC)

Just realized that eliminating page= would break the functionality of stringing multiple ref names together. I've never used that feature, there's enough of a fight getting people to accept individual citations without it being more confusing. Just my 2¢.—D'Ranged 1 VT^alk 11:45, 23 February 2016 (UTC)

Glad to see I'm not the only one using {r}: I think it's great! Not only is it cleaner in the source text than is < ref>< /ref>, but the superscript -type page #s are much better than having zillions of Harvard type footnotes saying, "Smith (1995), p. 5".

But I think it would be a huge mistake to do anything increasing the width of the rendered superscript, such as changing ^[1]:15 and ^[1]:15-6 to ^[1](p15) and ^[1](pp15-6). (If it were up to me even the colon would have been omitted in the first place i.e. ^[1]15.) If I'm reading you right you're proposing that |page do this but |p continue giving the old function, but that would change existing function.

I never knew {rp} had a {{rp|page=5}} flavor, which renders as -- I rarely use {rp}, but when I do I only use the {{rp|5}} form, which renders as . Even if there's some application for the form, it was absolutely stupid to trigger that with |page instead of some special syntax. EEng 21:08, 23 February 2016 (UTC) P.S. While we're here, what do you think about #pages, pages1, pages2, etc.??

I'm generally not in favor of a plethora of aliases, but understand how helpful they are in preventing errors.

—D'Ranged 1 VT^alk 01:30, 24 February 2016 (UTC)

I'm with you on that in general, but thanks for understanding. Done. EEng 03:55, 24 February 2016 (UTC)

pages, pages1, pages2, etc.?

Is there any reason I shouldn't make pages, pages1, pages2,... be synonyms for page, page1, page2,...? Many times I thoughtlessly typed e.g. pages and since the result is that the parameter is just ignored (so the page number information is silently omitted e.g. you get ^[5] instead of ^[5]:220), with no error message to alert you, it would be easy to never realize there's something wrong without careful checking of the output. EEng (talk) 22:29, 24 July 2013 (UTC)

Done. EEng 03:55, 24 February 2016 (UTC)

Improved; added remaining numerical parameters to template code (you missed a few). Also updated documentation to make it more informative and prettier. I highly recommend utilizing the template sandbox and thoroughly testing changes before committing them to the live template, by the way.

—D'Ranged 1 VT^alk 07:31, 24 February 2016 (UTC)

Good work. I don't dare make more than the tiniest change to a template at once. I fear, however, that R remains an acquired taste of the select few. Too bad, because it's so clean and so handy. The only thing I still really wish for is if list-defined refs could be rendered in the order in which they are defined, instead of according to first ref in the article. EEng 13:09, 24 February 2016 (UTC)

That's why the sandboxes are so handy—if you break the template, it doesn't affect anyone. As for rendering LDRs in whatever order is chosen for the list, I think there are folks working on that, but it's complicated. Surely that would only be helpful while editing, not for someone reading the article? It's critical that the notes appear in numerical order when viewing the article rather than editing it.

—D'Ranged 1 VT^alk 15:27, 24 February 2016 (UTC)

No! If LDRs would come out in the order they appear in the list of definitions, then we could have refs alphabetized by author name, which would be a magnificent improvement to complex articles. Take a look at Phineas Gage. Another editor (Mirokado -- best technical guy you'll ever know -- worked very hard (see the Talk archives for that article) to fashion what I think is a pretty darn good way of doing something like that (and of course, as with most good ideas around here, some asshole will show up someday to say that all articles have to be the same so you can't do that). But I'd rather we could have just put the refs in a refs= section (or several of them actually -- one For General Readers, one for Researchers and Specialists, etc.) in author-alpha order, and have them come out in the article in the same way. EEng 15:38, 24 February 2016 (UTC)

You're trying to reinvent a very old wheel. Footnotes have long been listed at the ends of pages or works in numerical order. The methodology used in Phineas is cluttering up the article's readability for the sake of organizing the footnotes, which is not the primary purpose of the existence of the article. Think of the reader, not the editor.—D'Ranged 1 VT^alk 15:55, 24 February 2016 (UTC)

I don't follow you. This is for the reader. How is it cluttering the article? If you mean in the article text proper, I can't see what you mean, since what you get is exactly the same as what you get with {r}, except with alpha,^[M] or alpha-numeral,^[M1] callouts instead of just numbers.¹ (And, in fact, the alpha/alpha-numeral callouts are narrower, horizontally, than they'd be if the usual machinery was used, because all the most commonly-cited sources are a single character, instead of being two- and three-digit callouts, which they would be with the usual machinery.)

If you mean in the Refs section down at the bottom, again it's what you get with the usual machinery, except things are organized in a way to allow the reader to understand which refs might be appropriate for further reading or research, depending on what he's interested in. Or am I misunderstanding you? EEng 17:41, 24 February 2016 (UTC)

I have decided this is not my circus nor my monkeys. I'm opting out of this discussion.
—D'Ranged 1 VT^alk 17:50, 24 February 2016 (UTC)

More shortened coding

I was bold and added the aliases |grp= and |g= for |group= to further shorten the coding seen by the editor and updated the documentation accordingly.

Please note that both EEng and I have labored mightily to make improvements and particularly update the documentation to be more robust, concise, clearer, and educational. Comments and/or criticisms from others would be welcome, however.

Thanks!

—D'Ranged 1 | VT^alk :  13:45, 26 February 2016 (UTC)

Good ideas! EEng 16:36, 26 February 2016 (UTC)

loc and redundant page/loc info? Feedback sought.

loc

Super-widely used so I'm hesitant to edit directly. Should we add support for 'loc=', to match the support in normal citations? I guess this would do it:

<includeonly>{{r/ref|{{{1}}}|{{{group|{{{grp|{{{g|}}}}}}}}}|{{{p|{{{p1|{{{page|{{{page1|{{{pp|{{{pp1|{{{pages|{{{pages1|{{{loc|{{{loc1|}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}<!--

-->{{#if:{{{2|}}}|{{r/ref|{{{2}}}|{{{group|{{{grp|{{{g|}}}}}}}}}|{{{p2|{{{page2|{{{pp2|{{{pages2|{{{loc2|}}}}}}}}}}}}}}}}}<!--

I'm wanting to use loc= at Copyright_status_of_work_by_U.S._subnational_governments but it doesn't work. I'll use p= for now.

--Elvey^(t•c) 18:15, 19 May 2016 (UTC)

Or not. Having counted and skimmed the !votes at the deletion discussion, I've decided I think the more standard, but less terse <ref> is better - and along the same lines, perhaps p= is better than loc=! --Elvey^(t•c) 18:24, 19 May 2016 (UTC)

Bug? Or am I doing something wrong?

I love this template. But…

In North Presbyterian Church (Manhattan), I'm having a problem.

In the first subsection titled "Permanent home", at the end of the 3rd paragraph, there is a double footnote, using the R template. If I add the parameter "1=" to either value, I get the Cite error message: "Warning: North Presbyterian Church (Manhattan) is calling Template:R with more than one value for the "1" parameter. Only the last value provided will be used." If I add "2=" to either, there is no problem. And there is no problem adding both. This happens even if there is a "p1=" value. And it happens everywhere, not just in this example.

At the end of the subsection titled "Temporary quarters", there is a triple footnote. I can't add any number-parameter(s) without an error.

Thanks for any help you can give me. Vzeebjtf (talk) 10:56, 30 June 2016 (UTC)

Since I haven't had my coffee, can you make an edit demonstrating the problem, then give the diff here? EEng 13:12, 30 June 2016 (UTC)

Sure.

• (cur | prev) 00:54, 1 July 2016‎ Vzeebjtf (talk | contribs)‎ . . (58,286 bytes) (+2)‎ . . (undo)
• (cur | prev) 03:06, 28 June 2016‎ Vzeebjtf (talk | contribs)‎ . . (58,284 bytes) (-42)‎ . . (undo) Vzeebjtf (talk) 05:00, 1 July 2016 (UTC)

What's going on is that unnamed parameters are assumed to be 1=, 2=, etc. in the order they're found. Thus in

{{r|1=1885-03-14|1885-03-16}}

the 1885-03-16 is interpreted as 1=1885-03-16, and therefore you might as well have coded

{{r|1=1885-03-14|1=1885-03-16}}

Then, the second occurrence of 1= overrides the first, so the 1=1885-03-14 might as well not be there.

After long experience I've found it's best to have a separate {{r}} for each ref, especially when there's p= as well. I just had too many times where I mixed things up when adding or removing one of a several refs withing the same {{r}}, and separate {{r}}s are easier to absorb by eye when looking things over.

Welcome to the club of people who love {{r}}. There seem to be three of us now. EEng 15:49, 1 July 2016 (UTC)

Might it be possible to fix the problem with the numerical parameters? Vzeebjtf (talk) 11:07, 2 July 2016 (UTC)

I guess my explanation isn't that clear. When you mix numbered and unnamed parameters the way you're doing, you're going to run into trouble sooner or later -- this has to do with the way all templates work, nothing specific to {{r}}. If you insist, you could code

{{r|1=1885-03-14|2=1885-03-16}}

but why not code simply

{{r|1885-03-14|1885-03-16}}

or, as I'm recommending

{{r|1885-03-14}}{{r|1885-03-16}}

– ? EEng 13:21, 2 July 2016 (UTC)

I get it. Thanks very much. Vzeebjtf (talk) 14:00, 2 July 2016 (UTC)

You'll get my bill. EEng 18:19, 2 July 2016 (UTC)

"Bundling" is a bad idea?

As mentioned in the thread just above this one, I stopped using the "bundled" forms long ago. The {{r|foo|bam|bar}} form is tolerable but of marginal value; but by introducing it we're forced to also explain forms like

• {{r|RefName|Bam|Bar|Bas|p1=100|p2=10–14|p4=§C}}
• {{r|1=RefName|2=Bam|3=Bar|4=Bas|p1=100|p2=10–14|p4=§C}}
• {{r|1=RefName|p1=100|2=Bam|p2=10–14|3=Bar|4=Bas|p4=§C}}

 – which I think are hopelessly overcomplicated to understand, a nightmare to maintain. I suggest we remove these from the main examples table and move them to the end as deprecated forms. EEng 16:43, 11 January 2017 (UTC)

As one of the apparently three users of this template, I've never had a problem understanding the bundling with locations, but I can't say for certain how often I've used the feature/option. The problem with just moving them to a separate place in the documentation and calling them "deprecated" is that there is a specific meaning here attached to "deprecated" parameters. I added an "Equivalent to" statement in the complicated bundled example that should make it clearer as to how it works and provide the alternative to use multiple {{r|}} calls rather than bundling them. Hope that helps!

—D'Ranged 1 | VT^alk :  21:32, 11 January 2017 (UTC)

(I like the changes you've made since I posted.) I don't have any real problem with bundling (though I've had a slipup or two) and I'm sure you don't either, because we know and love {r}. My concern is the effect of these quite confusing additional features on a potential adopter: "Look how complicated this gets!". Instead of deprecated, how about if we call those two rows Advanced? I still feel strongly that the first three rows show how simple and clean {r} is, and then #4 and #5 come along and make the reader's eyes go crossed, so I'd really like to move them to a separate "Advanced" table (or maybe just call it the "Bundling" table).

I guess under that philosophy we'd have to change the Comparison to < ref> examples as well. I don't know, maybe you and I are just shouting in the wind anyway. EEng 23:18, 11 January 2017 (UTC)

Moving page to reflist

Some editors have shown objections to the use of this template [2]. Can a template be made (say, {{rr}}) that's identical in use, but produces the quote and page number in the reflist? Example:

Source:

Brown<ref name="World's citations">Brown, James. ''The World's Citation Styles''. London, 2005.</ref> says it's the only "nice" reference style.{{rr|World's citations|p=5|q=Pointless comments from the book.}}

Text:

Brown¹ says it's the only "nice" reference style.²

reflist:

1. ^ Brown, James. The World's Citation Styles. London, 2005. 2. ^ "Pointless comments from the book." (Brown, 2005, p. 5)

François Robere (talk) 11:48, 28 April 2018 (UTC)

I'm afraid your suggestion makes no sense as something {r} might do, but {{sfn}} has such a feature (though personally I don't recommend using sfn). And the problem you're having stems from the fact that you're trying to mix a new citation style into an article that has an established one already. That never works. EEng 12:24, 28 April 2018 (UTC)

Keep in mind WP:CITEVAR --Emir of Wikipedia (talk) 15:53, 28 April 2018 (UTC)

Thanks. The problem was a lot of the citations were challenged by other editors for whatever reasons, so I looked for a way to include quotations and page numbers without creating a mess of sidenotes - which we already had, with many sources being cited twice in different styles. {{sfn}} seems good - what's the problem with it? François Robere (talk) 14:43, 29 April 2018 (UTC)

Complicated, fragile, creates huge lists of repetitive little footnotes which have to be read in conjunction with a separate source list. EEng 15:12, 29 April 2018 (UTC)

Which is just what I was trying to avoid, but others seem to prefer that over in-line markup... Thanks. François Robere (talk) 15:21, 29 April 2018 (UTC)

The elite and enlightened few use {r} in any new articles they create. The SUPER elite and enlightened use {{rma}}/{{ran}}. EEng 05:55, 30 April 2018 (UTC)

Discussion at…

…Help talk:List-defined references#Template:R Vzeebjtf (talk) 02:49, 3 May 2018 (UTC)

New quote feature

Kudos to Ahecht for adding the new |quote= feature. It's a shame only the elite few who use {r} in the first place will be able to enjoy it – paging D'Ranged 1, Mirokado(?), David Eppstein. And, of course, I wonder how long it will take readers to notice the little underlines. (Just to be clear, I'm not being sarcastic. It's really a shame more editors don't understand and use {r}. I love it – when I'm not using {{ran}} and {{rma}}, of course.) EEng 02:42, 16 November 2017 (UTC)

I like {{r}} as a way of making the source code for the article text clean enough that I can read it and find the text I want to edit, and move the reference details to the reference section where they belong. But I don't particularly care for annotations on the in-text footnote markers, so I only use it in its basic form where the arguments are all refnames. Ran and rma are useful, too, but for more specialized purposes; I am currently using r much more frequently. —David Eppstein (talk) 03:08, 16 November 2017 (UTC)

I use the |p= all the time, and while I don't see |q= seeing too much use, I can see how in a controversial article it's a good way to be transparent up front with the basis for a given passage. EEng 04:31, 16 November 2017 (UTC)

I use specific page numbers within a source with a larger range of pages all the time, and quotes from sources less often but still regularly. I just prefer to put those with the rest of the reference in the references section rather than in the article text. —David Eppstein (talk) 05:09, 16 November 2017 (UTC)

As you say, it is hard to notice hovering the mouse cursor to the dotted underlines will show the quoted text. And our guideline for accessibility is against the use of tooltips. It is a nice feature to have "quote" parameter, but how to display the information should be changed to be user-friendly. --Kusunose 09:26, 24 February 2018 (UTC)

Another issue with the quotes parameter is that it requires a page number, this template might be used for long articles which are paywalled and therefore you might want to quote the information it is supporting. Emir of Wikipedia (talk) 19:55, 28 March 2018 (UTC)

Agreed, but I couldn't find a good way to do that from a UI standpoint. Perhaps putting "[quote]" (as "&amp#91;quote&amp#93;") as the page number? --Ahecht (TALK
PAGE) 14:19, 30 April 2018 (UTC)

That seems like the best idea, thanks for suggesting that. The only problem I can think of is if the page parameter is analysed or used by something that literally requires a page number, but if nothing like that exists then this sounds great. Emir of Wikipedia (talk) 20:05, 30 April 2018 (UTC)

No, that will do something awful: for example

Smith has an opinion.{{r|foo|p="This is the text of Smith's quotation"}}

gives

Smith has an opinion..

That looks good. Emir of Wikipedia (talk) 18:29, 1 May 2018 (UTC)

EEng 00:32, 1 May 2018 (UTC)

You could also use any of the suggested value for {{cite web}}'s |at= field (section (sec.), column (col.), paragraph (para.), etc.). --Ahecht (TALK
PAGE) 20:46, 30 April 2018 (UTC)

That's sensible. EEng 21:31, 30 April 2018 (UTC)

Section notes

Vzeebjtf (talk) 10:59, 6 May 2018 (UTC)

The quote parameter stops parsing when it encounters a single quote character

Thank you for creating this R function with page number and quote!!! I really like it as an improved way to site the same reference multiple times with a different quote each time. Thanks for making this function!!!

I have a small problem with it, though. It stops parsing the quote whenever it encounters a single quote (') mark, and I can't seem to escape it with a backslash character. Is there some way to use the apostrophe (indicating possessiveness) inside a quote? See below demonstration.

Citation r|Test1|p=100|q=See this will stop' at the single quote mark

Citation

Thanks! ----Avatar317 (talk) 23:59, 23 July 2018 (UTC)Avatar317

• Why it does this I have no idea, but if you use &apos; you should be OK. EEng 01:29, 24 July 2018 (UTC)

Does the Usage table need copy-editing?

In row 5 column 3 first line, the page range for Bar should be shown instead for Bam. In the second line, "quotes" should read "pages". Vzeebjtf (talk) 23:10, 4 May 2018 (UTC)

Fixed, thanks! EEng 02:22, 16 July 2018 (UTC)

the whole doc has a RefName/Bal conflict between the parts of the documentation v the parts of the coded examples Dave Rave (talk) 10:57, 18 April 2020 (UTC)

Ongoing talk

Talks about {{r}} are going on here. Est. 2021 (talk · contribs) 19:23, 7 February 2021 (UTC)

Typical confused discussion, but welcome to the {r} fanclub. "For the select few." EEng 00:54, 26 August 2021 (UTC)

Suspend replacing of ref by Template:r in citations

I'm moving the hint on this very old central discussion (from 2010!) from the header of this talk page into a dummy thread, so that it will be archived at some point in the future:

Relevant discussion at

→ Wikipedia:Centralized discussion/Citation discussion#Suspend replacing of ref by Template:r in citations

--Matthiaspaul (talk) 12:13, 27 August 2021 (UTC)

• Huh. So 11 years ago editors confusedly thought that {r} is somehow related to list-defines refs. And today that misapprehension lives on! Plus ca change. EEng 12:56, 27 August 2021 (UTC)

Accessibility concerns with quote parameter

Hi all. I noticed this template's quote= parameter being used at California housing shortage, and I'm concerned about accessibility for a few reasons.

• They're not good for screenreaders (I asked at WPACCESS and Graham87 confirmed)
• They're hard to read for everyone, because default browser tooltips are not visually designed for many sentences of content (smaller text, yellow background).

As Graham87 said over there, "But I have no idea what should be done here", I don't either. I like the idea, but I hope someone can dream up a better method of implementing it. That's all, thanks. :) Quiddity (talk) 06:36, 22 November 2018 (UTC)

I agree. This is more than an accessibility concern for people with visual impairments. Even for readers who aren't using a screenreader, the page and quote parameters make reference anchors easy to misunderstand. When I first saw them in the article for Kickstarter, I thought there was a broken template. It isn't clear that the number following the reference anchor represents a page number and it isn't obvious that the text in the tooltip is a quote from that page. I think the intended functionality is useful in theory, but it could be implemented better in practice. TJScalzo (talk) 23:08, 5 July 2020 (UTC)

Because displaying the quote as normal text in the middle of the prose is no option, the quote must be seen as an additional goodie for those who do not have accessibility problems, only.

As a workaround which also works for disabled people, I suggest to repeat the quote in the core citation {{r}} refers to:

If this happens to be one of our CS1/CS2 citation templates, they all support an optional |quote= parameter alongside with |quote-page= and |quote-pages= parameters to specify the page or pages, the quote has been lifted from. (These parameters are specific to the quote and separate from the normal |page= and |pages= CS1/CS2 citation parameters which can be used in parallel. The latter would be used to combine all the individual pages from the various {{p}} short references refering to this citation.)

CS1/CS2 citation templates even support |script-quote= (for quotes in non-Latin scripts) and |trans-quote= (for English translations of non-English quotes).

Similar to combining the page numbers of multiple {{r}} short references into the |page= or |pages= parameter of the CS1/CS2 core citation, multiple quotes from those {{r}} references would have to be combined into a single |quote= parameter of the underlying CS1/CS2 core citation. In order to somehow separate them within that parameter, something like "[…]" could be used between the sections.

This way, people without accessibility problems can take advantage of the "short/individual quotes" embedded into {{r}}, whereas the others will have to check the "full/merged quote" in the core citation.

--Matthiaspaul (talk) 23:26, 25 August 2021 (UTC)

As a possible solution to this problem I was tinkering with the idea of having to define a quotation only once and use the

<section begin="section_name"/>section_content<section end="section_name"/>

mechanism to semi-automatically pull it into other places using something like:

{{#lst:{{FULLPAGENAME}}|section_name}}

Unfortunately, sections defined inside the <ref></ref> of the core citation cannot be pulled into other places, but defining a section outside of a citation's <ref></ref> and pulling its contents into the citation's <ref></ref> works according to my testing. I ran various tests defining a test section on a page and then pulling its contents into a citation. If multiple identical named sections are defined on a page they are all merged together (unfortunately without a separator) when being pulled.

Based on this, the general idea was to let {{r}} automatically define sections for the

• page (with section name "cite_page-<group>-<name>")

and

• quote (with section name "cite_quote-<group>-<name>-<page>")

contents and then use to-be-created templates like {{r-page}} (with |group= and |name= parameters) and {{r-quote}} (with |group=, |name= and |page= parameters) to pull the contents into the |pages= or |quote= parameters of CS1/CS2 templates like:

|pages=3, 5, {{r-page|name=Ref1}}, 354

or

|quote-pages=107 |quote={{r-quote|name=Ref1|page=107}}

(Unfortunately, CS1/CS2 templates have no access to the |group= and |name= parameters used in the framing <ref></ref>.)

Since this needs to work for single as well as multiple snippets we need some kind of "invisible" separator to be appended to the snippets. Something like a comma would work for testing, but would look ugly at the end of {{r}}. However, U+200C, ‌, or {{zwnj}} should do the job. At a later stage, CS1/CS2 templates could be easily improved to handle it as an additional item separator for lists of pages in |pages=, translating it into ", " for display and metadata, and to convert it into something like " […] " in |quote=.

Unfortunately, this all seems to work for as long as the sections are defined on the same page, but so far I could not get it working when the sections are defined in a template like {{r}} and then transcluded into a page.

To illustrate this I have added some test code to {{r/ref/sandbox}} [3] which, at present, additionally creates a static test section named "cite_test" containing just "TEST". If someone manages to pull this test section into an article somehow, I'm sure the other dynamically created sections can be pulled into it as well.

--Matthiaspaul (talk) 22:09, 26 August 2021 (UTC)

Tracked in Phabricator
Task T39256

Tracked in Phabricator
Task T181482

I'm not completely sure about it, but it seems I was caught by [4] and [5]. So, if anyone has ideas...

--Matthiaspaul (talk) 17:50, 27 August 2021 (UTC)

I think I have found a workaround using a completely different approach. It won't be useful in all possible cases, but could be useful at least in some:

{{r}} now supports to not only invoke a citation defined elsewhere, but has been enhanced to define citations through a new |reference=/|r= parameter as well. Additionally, using the new |annotation=/|a= parameter, it allows to define any kind of extra content which gets appended at the end of an already defined citation, even from multiple places within the article. The |a= parameter accepts any kind of input, but also recognizes two special tokens: "p" is replaced by the page number defined through |page=/|pages=/|p=/|pp=, and "q" is a placeholder for the quote as it would be displayed in the tooltip, so, by specifying |a=q, a quote defined in a short reference can be made part of the core citation as well without having to duplicate the contents. These strings will be appended to the core citation in the order as they appear in the article, so this is not as flexible as the {{r-quote}} method I proposed above (which would have allowed to control where the contents gets inserted - also in parameters of a citation template) (Source code: {{r |n=RefName |p=346 |r=Demo Citation.}}), but still I think this feature (Source code: {{r |n=RefName |p=102 |q=Quote |a=q}}) might be useful in some scenarios.

--Matthiaspaul (talk) 13:07, 29 August 2021 (UTC)

Breaking change

Were some breaking changes made to the implementation of this template? The ;login: article broke, and I fixed it with this change. Maybe quotes are no longer allowed, or the leading semicolon was the problem? -- Mikeblas (talk) 16:10, 30 August 2021 (UTC)

Hi Mike. Thanks for reporting. Yes, there was a change in the handling of arguments with quotes with the intent to make them optional for as long as no spaces are in the label. Well, the name in your example ";login:/w18/f" is odd, but I will investigate. --Matthiaspaul (talk) 16:58, 30 August 2021 (UTC)

The offending character in this case is the leading semicolon. Semicolons work in other positions, and other punctuation like .,-+ works also in the first position, including digits, but :;#! and probably a few more don't. See also: Help:Template#Problems_and_workarounds

--Matthiaspaul (talk) 19:19, 30 August 2021 (UTC) (updated 20:11, 30 August 2021 (UTC))

Thanks for lookin' into it! These restrictions are new. Will they be documented? Is there a plan to find affected articles and fix them up? -- Mikeblas (talk) 19:48, 30 August 2021 (UTC)

This has been fixed meanwhile. (I cannot guarantee that we can allow these special characters as first characters forever, depending on other features, but at least for now it's possible again.) --Matthiaspaul (talk) 17:49, 31 August 2021 (UTC)

New features

Hi, I have added a few new features to the {{R}} template:

• Added enumerated named parameters |namen=/|nn= in parallel to the unnamed parameters |1/2/3/4/5/6/7/8/9= for symmetry with the other named parameters.
• Added new enumerated parameters |quote-pagen=/|quote-pagesn=/|qpn= to optionally define a page number displayed in front of a defined quote in the tooltip.

If the page number is the same as that defined in the corresponding page parameter, a special symbolic token "p" can be given instead; thereby the page number does not need to be repeated. (If this token would be conflictive with actual page numbers, we could choose a different token like "*".)

• Added new enumerated parameters |referencen=/|refnn=/|rn= allowing to define references inside the template in addition to the old functionality to invoke references defined elsewhere. This can be combined with the template's local |page= and |quote= parameters and works for inline definitions as well as with Wikipedia:List-defined references in the References section. The definition itself can be given as plain text or provided through a citation template like our suite of CS1/CS2 templates (and many others).
• This has several advantages over the normal way to define references inside of <ref></ref>:
  • It looks quite nice to use template syntax rather than <ref></ref> syntax inside the |refs= parameter of {{reflist}}.
  • It allows for nested invocations and/or definitions of references (including jumping between multiple groups and up to five recursion levels deep when counting in the root reference).
  • The Pipe trick to expand links now works inside of reference definitions.
  • Substituting works as well.
• Similar to defining a citation through |referencen=/|refnn=/|rn= it is now also possible to provide additional annotation through |annotationn=/|annotn=/|an=. This will be appended at the end of a citation defined elsewhere. Both methods can be combined. This feature can be used to collect commentary specific to the various "{{rp}}"-style short references in the full citation. It can also be used to bundle multiple citations defined in different locations of the article under one entry.

The parameter also takes two special symbolic tokens: "p" (and "page") will be substituted with the page number defined in the page parameter, and "q" (and "quote") will be substituted with the quote as it would be shown in the tooltip (that is, with or without the quote page prefix depending on if this was defined as well or not). This eliminates the need to repeat these values if they should be appended to the core citation as well. (If these tokens would be conflictive with actual page numbers and quotes, we could choose different tokens like "*" and "**".)

There are probably other interesting applications as well (like collecting quote snippets distributed all over the article in the core citation, or sending text defined in the context of a short reference to the core citation including backlinks, but this might need some more experimentation).

--Matthiaspaul (talk) 01:48, 29 August 2021 (UTC) (updated 12:07, 29 August 2021 (UTC), 18:24, 31 August 2021 (UTC))

• Really glad someone's giving {r} the attention it deserves! Haven't had my coffee so I was only able to drag my bleary eyes over the above, but ... question: In the past I've used {{refn}} for the first use of a source, and {r} for additional uses. What you've done is better. But what about |group (not that anyone uses it, I suspect)?
  A further comment, though not really saying there's anything to be done about it: The feature of bundling multiple things in one invocation (like {r|foo|bar|bah}, or {r|1=foo|2==bar|3=bah}, or (if I'm understanding) your new syntax {r|name1=foo|name2=bar|name3=bah}) always was, I think, a mistake. It has very little advantage, and is really confusing and error-prone, especially the {r|foo|bar|bah} form. I regret seeing it extended to the new things you've added, and would almost advocate fixing articles to not use it, and then removing the functionality completely. EEng 15:57, 29 August 2021 (UTC)

Hi, |group= should work as well, see the example on the (crude) doc page.

Regarding support for multiple citations in one template call, I was wondering about this as well but since adding support for it was easy (and the calling syntax would not really become easier if we would remove support for it) I implemented it for the new features as well. From a user's perspective it would probably be strange if some features only work for one and others for all citations. Therefore, there is no pressing need to remove support for multiple citations in one at present. --Matthiaspaul (talk) 18:13, 29 August 2021 (UTC)

The more I think about it, the more I think some clever person like you should write a script to hunt down and eradicate all instances of "multiple", and then just rip out all that code. I mean really, what's the benefit? You get to code {r|foo|bar} instead of {r|foo}{r|bar}? Big deal. And since a big part of the attraction of {r} is reducing the visual footprint in the source, consider that when do "multiples" with additional parameters, it actually increases the byte count (since you only save the opening and closing braces once, and the r| once, but you have to keep appending the n's to each parameter). A great example of a good idea badly thought through.

Two other things:

• (1) Before anyone starts using it, please just junk the |r parameter. Having an r| parameter in an {r} macro is just asking for trouble, and it's not worth the compaction (since it will always be used with a relatively long string of text).
• (2) To the extend possible, is the parm naming and usage consistent with {refn} and {ref} and whatever other templates we already have, with overlapping, conflicting, and confusing functions. (To be honest I don't think I've ever used {ref} or know what it's for.)

EEng 18:54, 29 August 2021 (UTC)

Broken

See Latinx for an example: it is now appearing as "Template:R" in articles. Crossroads ^-talk- 19:03, 29 August 2021 (UTC)

Now it's appearing as a small 1 in brackets lower than normal refnotes, but are empty when clicked on. Crossroads ^-talk- 19:06, 29 August 2021 (UTC)

Reverted. Well, Matthiaspaul, back to the old drawing board! [6] EEng 19:10, 29 August 2021 (UTC)

P.S. for Crossroads: see WP:PURGE if an article doesn't go back to normal. EEng 19:18, 29 August 2021 (UTC)

Thanks! Template:Rp and Template:Efn were also being faulty but have stopped doing so. Efn wasn't even edited recently. Is Template:R transcluded in those as some sort of "sub-template"? Or was the problem some sort of sub-template of all three? Crossroads ^-talk- 19:21, 29 August 2021 (UTC)

It's easy to believe that there's caching and optimizing stuff going on under the hood which acts as a conduit for one template's misbehavior to surface in the behavior of other templates. EEng 19:44, 29 August 2021 (UTC)

(edit-conflict) I haven't seen the problem so far, therefore it's a bit difficult to hunt it down, whatever it is. Can you give a specific template call in Latinx where you saw the problem? What exactly did you see? Now that {{r}} is back to its previous state, do you still see any problem with it anywhere?

{{rp}} has not been reverted, does it still show any problems?

The templates use some of the same library functions (string.replace and trim quotes), but I haven't edited them. Otherwise they are independent to the best of my knowledge.

--Matthiaspaul (talk) 19:55, 29 August 2021 (UTC)

I'm not sure what "specific template call" means. What exactly I saw was that in the article, instead of a ref note, the text "Template:R" appeared, with a blue link leading to the template. Then a short time after that, Template:R and only Template:R showed up as "[1]" in small text like a ref note, only with a one, but contained no information and was positioned lower in the line of text than a working ref note. The article looks good now, so the timing of the reverting of Template:R makes me think that was the issue for all three templates. Crossroads ^-talk- 20:01, 29 August 2021 (UTC)

MP, go back to your last version and do the "Preview page with this template" thing on Phineas Gage. Everything goes haywire. EEng 20:06, 29 August 2021 (UTC)

Okay, the problem appears to be down to:

"Warning: Post-expand include size is too large. Some templates will not be included"

--Matthiaspaul (talk) 20:36, 29 August 2021 (UTC)

I have reenabled the new code except for the "context support section" feature. The two reported articles and a few others I checked now seem to render without the reported problems, so let's give this a try for a couple of days to see if it's really stable. In the meanwhile I will think about how to possibly improve the efficiency of the "context section" stuff. In the worst case, we'd have to switch to Lua for this, but I hope we can avoid this.

--Matthiaspaul (talk) 21:25, 29 August 2021 (UTC)

Switch to Lua or ... rip out the "multiples" code (which -- correct me if I'm wrong -- makes everything 10X as big)? EEng 00:29, 30 August 2021 (UTC)

The more I think about this, the more I think we should do it. Your changes make {r} a far more attractive facility, but the "multiples" features add unnecessary complexity to its documentation and use (not to mention its implementation) that might turn people against it. As a first step, how would you feel about my recruiting someone to survey articles to see how many use the "multiples" feature? Or can you do that? EEng 17:39, 30 August 2021 (UTC)

Looks like I had the mute on. OK, can you hear me now, Matthiaspaul? EEng 04:56, 1 September 2021 (UTC)

See: #Proposed new calling syntax

Another breakage example

(I briefly skimmed the discussions above and didn't see anything that seemed related, but apologies if this is redundant.)

Kiwi Farms has a bunch of really garbled markup being produced by this template (e.g. a block of gibberish that looks something like }}}}[10]quote|: }}""|}}|follow=Veale|group=}}}}}|:page8-9}}}}}}}). I'm guessing this is related to the recent changes. Colin M (talk) 20:58, 1 September 2021 (UTC)

Please refresh the page (F5 with most browsers). Is it gone now? --Matthiaspaul (talk) 21:30, 1 September 2021 (UTC)

Yup! Thanks. Colin M (talk) 22:04, 1 September 2021 (UTC)

Error on documentation page

Please do a find for "Context6" on the documentation page to see a rendering error. I don't know if this error just appeared recently, but I assume so, given all of the fiddling that is happening with this template. – Jonesey95 (talk) 14:22, 3 September 2021 (UTC)

Yep. I have observed this as well, Jonesey. Since I have seen it working and not working on and off over a couple of days, I first thought it would be a caching issue after updating the template. However, if you go to the actual /doc subpage and through one preview cycle there, it always works. This would indicate an issue related with transclusion (possibly related to the same bug in MW mentioned earlier). Either way, if it is used on the same page where {{r}} is used (the normal use case), it works.

Added a comment to the doc that readers will have to visit the non-transcluded page.

--Matthiaspaul (talk) 22:39, 3 September 2021 (UTC)

It would be possible to "mute" this specific error message and automatically disable the feature when this condition is detected, so that the dotted underline disappears automatically when the page gets transcluded somewhere. On the other hand, this might work in the future, so it might be useful to see the error message. I won't mute the message for now, so we can further study the effect.

--Matthiaspaul (talk) 10:09, 4 September 2021 (UTC)

Line breaks

@Matthiaspaul: User:Nathan Obral and I are noticing also some unexpected line breaks at pages like WHKW as a result of whatever changed. Sammi Brie (she/her • t • c) 17:20, 31 August 2021 (UTC)

@Matthiaspaul and Sammi Brie: A better example is here on the KWKW page where one paragraph got broken up into strings of sentences with double line breaks, plus the whole paragraph is transcluded altogether, so it's difficult to edit anything visually. Nathan Obral • he/him • t • c • 17:32, 31 August 2021 (UTC)

Thanks for reporting. This was down to the new line-wrapping code (so that long lines of ^[1] links do not keep browsers with narrow viewports from wrapping (as it happens with {{rp}}. It could be disabled with |wrap=n, but this was meant as an exception when not wrapping around would be actually important, not as a fix to the problem. I have temporarily commented this out again until a more compatible method has been found. Checking the page I can no longer see the problem. Can you confirm that it's fixed for you as well?

--Matthiaspaul (talk) 17:47, 31 August 2021 (UTC)

Matthiaspaul, it doesn't appear now. Sammi Brie (she/her • t • c) 17:54, 31 August 2021 (UTC)

@Matthiaspaul and Sammi Brie: I concur, it's fixed. ^-^ Thank you and hopefully a workaround can be had because I do like that idea. Nathan Obral • he/him • t • c • 18:03, 31 August 2021 (UTC)

In order to be compatible with most browsers I used a combination of <wbr/> and &zwsp; (zero-width space) to indicate the possible line-break locations after each reference in <sup>superscript sections</sup> (outside of superscript sections, this problem does not seem to exist). According to {{wbr}}, <wbr/> is known not to work (but break silently) in IE since including version 7, whereas ZWS is compatible with IE earlier than version 7. Other browsers seem to support both. I don't use IE, but I also saw a problem with WBR in current versions of Firefox, not with ZWS. Therefore I have reenabled the wrapping code with ZWS only, and it works for me now. If you again see problems with other browsers (and can confirm that they go away if you temporarily add |wrap=n to the offending {{r}}), please report. Thanks. --Matthiaspaul (talk) 14:01, 1 September 2021 (UTC)

This is no longer necessary as the new (old) default is "no" now. If someone wants the special wrapping behaviour to be enabled (for example in conjunction with long lines of references with superscript page info, |wrap=yes can be used for this.

--Matthiaspaul (talk) 16:15, 6 September 2021 (UTC)

Problems with number conversions

Category:Pages using infobox cyclist with atypical values for height or weight has several articles today with refs that are causing errors. Same thing in Lometa Odom, but here is is flagged as a Convert errors. All are caused by using {{r}}. No problems if the ref is changed to use <ref> tags. MB 02:14, 2 September 2021 (UTC)

Hi, this is caused by the auto-wrapping code appending a &zwsp;. It can be disabled by adding |wrap=n to the {{r}} template call.

We could change the default to off, but if it really only affects those ca. four pages listed in the category at present, the benefit of having it enabled by default might be higher for all the other articles. I'm leaving it enabled for now so we can study the effect.

On a different note, the {{infobox}} code must have special code to accept and deal with reference links in the given value, so another solution might be to add code there to let it also accept superscripts <sup> and spans <span> (at least some types), otherwise it will also choke up on {{rp}} (and, in fact, it does) and {{r}} (when using any of the features which cause something to be attached to the reference link).

So, if you see this error happening anywhere else please report here even if you can make it work by |wrap=n.

--Matthiaspaul (talk) 08:03, 2 September 2021 (UTC)

In the case of {{Infobox basketball biography}} (possibly some other {{Infobox}} class templates as well) there exist special parameters |height_footnote= and |weight_footnote= which can be used instead of |height_cm/m/in/ft= and |weight_kg/lb= to disable the check. Thanks to Bagumba for the hint. See: Template_talk:Infobox_basketball_biography#Warning_about_"convert_errors"_in_some_parameters_in_conjunction_with_embedded_citation_templates_R_and_Rp

--Matthiaspaul (talk)

This is no longer necessary as the new (old) default is "no" now. If someone wants the special wrapping behaviour to be enabled (for example in conjunction with long lines of references with superscript page info, |wrap=yes can be used for this.

--Matthiaspaul (talk) 16:15, 6 September 2021 (UTC)

Broken again -- spacing

As of this morning, all invocations of {r} that come at the end of a source line e.g.

Smith won.{{r|foo}}

He was happy.

come out like this:

Smith won.He was happy.

with no space after the cite callout. If the two code lines are merged (with a space after the {r}, of course), things are OK. I haven't been editing for a few days so I don't know when this happened. What's going on?

Just noticed this affects {rp} as well. I fear this code is reaching the complexity tipping point. EEng 14:52, 6 September 2021 (UTC)

Can you point to an instance, where this is occuring? It can only be caused by the code dealing with wrapping. There are only a few isolated locations dealing with this, so it should be easy to fix. Just for a test, does it disappear if you add |wrap=n to the call?

--Matthiaspaul (talk) 15:10, 6 September 2021 (UTC)

I think I have meanwhile understood your description and could construct a test case, where it was fixed by adding |wrap=n. I think the solution is to change the default to "no". I am going to implement this now. --Matthiaspaul (talk) 15:30, 6 September 2021 (UTC)

Done and fixed.

Smith won.{{r|foo}}

He was happy.

[outdent for testcase]

Smith won. He was happy.

[indent for thread]

Smith won.{{r|foo|pp=8, 12-14}}

He was happy.

[outdent for testcase]

Smith won. He was happy.

[indent for thread]

Smith won.{{r|foo}}He was happy.

Smith won.He was happy.

Smith won.{{r|foo|pp=8, 12-14}}He was happy.

Smith won.He was happy.

Smith won.{{r|foo}} He was happy.

Smith won. He was happy.

Smith won.{{r|foo|pp=8, 12-14}} He was happy.

Smith won. He was happy.

References

Default wrapping behaviour is now exactly (non-existent) as it was before the feature additions. If someone wants successive lines of references with superscript :page info to be wrapping, s/he can add |wrap=y[es] to invoke the new special behaviour and to allow wrapping even inside of longer page descriptions |wrap=f[orced] (but, in the latter case, if this will actually cause inline wrapping depends on the browser and CSS/skin).

--Matthiaspaul (talk) 15:54, 6 September 2021 (UTC) (updated 17:19, 14 September 2021 (UTC))

There's some serious misunderstanding here. This isn't about wrapping or breaking, only about what was a missing space (as in the examples I gave in my OP). None of the examples given should output a linebreak, each example's output should be on a single line; in particular, the output you show for the first two examples is not the correct output -- again, they should both render on a single line:

Smith won.^[1] He was happy.

Now as it happens, it does work that way -- the right way -- right now, so if you're planning to change it to the way you show in your first two examples above, don't do that. Please clarify. EEng 16:33, 14 September 2021 (UTC)

;-) I originally had problems to understand your example until, after rereading it several times and trying out various combinations, I understood it and could reproduce the problem. (Once understood, your description was clear enough, but that it took a while to understand was apparently in the nature of problem.)

I then changed the wrapping code so that it produces the same output as before by default (in so far, it had to do with line breaks and wrapping behaviour as well). Later, I added the testcases to this thread for illustration purposes and possible future reference, but it happens that the desired (and actual right now) behaviour cannot be shown with colon thread indentation. Perhaps there's some workaround for this, but I have now just outdented the two corresponding examples above to show that it actually works as desired and everything's fine again. :-)

--Matthiaspaul (talk) 17:19, 14 September 2021 (UTC)

Hyphens to dashes

The syntax of this template is complex enough that I didn't want to attempt it myself, buy this template should use {{#invoke:String2|hyphen2dash}} to convert ranges such as "1-2" to "1–2" per MOS:RANGE. The CS1/CS2 family of templates already do this. --Ahecht (TALK
PAGE) 03:58, 1 September 2021 (UTC)

N-O no! In the isolation of the little superscripts where these page ranges will appear, there's absolutely zero reason to increase the visual footprint in slavish submission to a distinction (hyphen vs. dash) which is irrelevant there. In other words, you want to change

this^1-2 to

this^1–2

...why?

P.S. I see some busybody slave to WP:MISSSNODGRASS has already worked their magic on {{rp}}, turning hyphens to ndashes there. Jesus, what a counterproductive waste of time. EEng 04:51, 1 September 2021 (UTC)

Actually, I was already tempted to add something like this, but it might have to wait for some internal reorganization (or switch to Lua) to keep the code manageable. I do consider it worthwhile because judging from the amount of discussion these little hyphens and dashes have caused in the CS1/CS2 forums over the years, there are quite a number of people who really care about them (are obsessive about them?), and we also need it to properly distinguish between a page range and a chapter-relative single page. The good thing right now is that {{r}} does not generate any metadata at present, so we are at least not guilty to trash the metadata. --Matthiaspaul (talk) 12:15, 1 September 2021 (UTC)

I ran a test, but removed it again as it needs some more work as a stand-alone routine than as part of CS1. It does not handle well the case of HTML entities like § (the semicolon of the entity will be converted into a list comma, and it also converts hyphens to endashes if they are encoded as {{hyphen}} - it shouldn't, see Help:Citation_Style_1#Pages. Also, the code does not support our ((accept-this-as-it-is)) syntax.

--Matthiaspaul (talk) 21:40, 1 September 2021 (UTC)

See also:

• Template_talk:Rp/Archive_1#Dashes_and_en_dashes
• Template_talk:Rp#New_hyphen2dash_code_breaks_semicolons?
• Help_talk:Citation_Style_1#{{hyphen}}_converted_to_dash
• Talk:Antoine_Ephrem_Cartier/GA1
• Template_talk:Sfn#Add_automatic_endash_for_page_number_range?

--Matthiaspaul (talk) 00:18, 2 September 2021 (UTC) (updated 21:25, 2 September 2021 (UTC), 12:54, 13 September 2021 (UTC))

@Matthiaspaul Breaking semicolons has been fixed and accept-this-as-is syntax has been implemented. CS1 does convert {{hyphen}} to an endash, despite what that help page says (for example, "{{cite book|title=Title|pages=1{{hyphen}}2}}" renders as "Title. pp. 1–2.") --Ahecht (TALK
PAGE) 02:24, 2 September 2021 (UTC)

This has now been enabled for |pages=/|pp= and |quote-pages=/|qpp= in {{r}} (and {{rp}} and {{ran}}). (In {{rp}} it is also enabled for the first unnamed parameter.). --Matthiaspaul (talk) 10:04, 12 September 2021 (UTC)

• Am I to understand that it now works one way for |p= and another way for |pp= ? Your analogy (near the top of this thread) to CS1/CS2 is inappropriate; hyphens, ndashes, and mdashes give subtle signals about the relationship between the two things on either side, and part of that is their visual relationship to other stuff on the line; but none of those things apply in the teensy, isolated type of superscipts. Please remove this "feature", at least as far as what's rendered on the page; if you want to output an ndash in some metadata, that's fine. EEng 20:26, 13 September 2021 (UTC)

This works exactly like with CS1/CS2 citation templates and the family of {{sfn}}- and {{harv}}-style templates. |page=/|p= is for a singular page only, |pages=/|pp= is for plural pages like page lists or ranges, or combinations thereof, and |at= (and its alias |loc=) is for other kind of in-source-location information, like sections, folios, paragraphs, columns, lines, etc. Depending on which parameter is chosen, the interpretation of the data and consequently also the visible output, tooltips and resulting annotation formats differ slightly. Something like |page=4-5 refers to a single page named "4-5", whereas |pages=4-5 refers to a page range 4–5. Since en-dashes are difficult to enter on most keyboards, most people will (have to) write 4-5 when they actually mean 4–5. Therefore, when one of the plural page parameters is used, the template automatically converts this into endashes so that the output becomes conformant with the MOS. The template even handles cases such as a range of chapter-relative pages "4-5-4-7" correctly (4-5–4-7), however, there are rare cases like "4-5, 5-7", which the template would interpret as two page ranges rather than two chapter-relative pages. In these cases, the accept-as-written-markup can be applied ("((4-5)), ((5-7))" or "((4-5, 5-7))") to tell the template that this should be interpreted as chapter-relative pages with hyphens rather than ranges with endashes. This scheme is the result of uncountable discussions how to best handle hyphens and endashes in citation page information, so it makes sense to let most (or all) citation templates use the same parameter names and handle them the same way, in particular since they can be combined. This improves the user experiences and thereby the acceptance of the r-range of citation templates.

I understand the argument that the page information should be short, but I can't see why our normal MOS rules would not apply to superscripts. There's certainly no need to go to the extremes and sacrify readability or proper spelling for this. Also, the width difference between hyphens and endashes is small enough so that, if there is enough room to tolerate a hyphen, an endash should be tolerable as well in my opinion.

--Matthiaspaul (talk) 23:49, 13 September 2021 (UTC)

MOS is meant to be applied with common sense, which means not mindlessly transferring the stuff intended for one context to other contexts with different or additional considerations. I already said why that principle has a role here here: hyphens, ndashes, and mdashes give subtle signals about the relationship between the two things on either side, and part of that is their visual relationship to other stuff on the line; but none of those things apply in the teensy, isolated type of superscipts. So, for example, in

Jean-Baptiste won the election of 3–6 September 2015—the first election in 20 years.

if you changed the ndash to a hyphen:

Jean-Baptiste won the election of 3-6 September 2015—the first election in 20 years.

it just looks wrong, because the experienced eye expects the three different relationships to be signaled in three different ways. Now turning to the case at hand (superscipts generated by {r} etc.), in

Jones arrived next^{[3]:1-2–1-5}

the two different relationships are crucially distinguished. But in

Smith was first^[1]:1–4 Jones came later.

it just doesn't matter, because there's no context, nothing to compare it too. If, instead, you have

Smith was first^[1]:1-4 Jones came later.

it does the same job in a less intrusive way.

I'll say it again: formats and punctuation exist to give a semantic signal to the reader; they are not an end in and of themselves. In the isolation of the last example I just gave, one little line sends the same signal as the other, just one is less visually intrusive. So I'm asking you, in the special case of |pp5-6 -- that is, numberHYPHENnumber, not numberHYPHENnumberHYPHENnumberHYPHENnumber -- to leave the hyphen a hyphen in the rendered output. In emitted metadata used by some machine downstream, sure, use an ndash. EEng 16:22, 14 September 2021 (UTC)

I understand what you write (and also think I'm among those who apply the MOS with a good amount of common sense), but there is a significant semantical difference in your example (for those using a font in which hyphens and endashes are even distinguishable):

Smith was first^[1]:1–4 Jones came later.

vs.

Smith was first^[1]:1-4 Jones came later.

The first one is a range of four pages, the second one is a single page named "1-4" (such page numbers are very common in publications which are put together from different sources, are frequently reorganized, or updated chapter-wise so they use chapter-relative page numbers). The difference is small (so it's hardly visually intrusive at all), but to the trained eye it is immediately recognizable, also per your it just looks wrong, because the experienced eye expects the [...] different relationships to be signaled in [...] different ways. From the endless discussions at CS1/CS2 (and personal experience with other editors when it was me who was not inserting the correct dashes in article editing) I know we have many editors who are very picky about this, too picky if you ask me, but still, if we can please them, I don't see why we should not give them the visual clue they want when we can. Also, thereby we achieve consistency across almost all citation templates, which is quite desirable from a user's perspective and lets our various citation systems look more as if they were designed with common vision and goals in mind instead of as individual pieces which do not fit together well.

When I look at the template's documentation and many articles already using r-style templates, other editors are using endashes to indicate page ranges, and they ever were (and still are) displayed by the templates as endashes in the superscripts, so this is nothing new at all. We have gnomes and even bot tasks trying to spot usage errors and correct them, even in superscripts, which also indicates that using endashes for ranges is desirable for many and well accepted and established practise. The only thing that is new is that the code is now smart enough to fix the appearance of those remaining occurences where the editors either didn't know about the differences between the dashes or had difficulties to enter them correctly. I think that's a win for everyone.

--Matthiaspaul (talk) 18:22, 14 September 2021 (UTC)

Multiple links to nested citation?

The article gives examples of a hack to produce nested citations:

Lorem ipsum{{r|n=C1|r=Citation 1}} dolor sit amet,{{r|n=C1|p=23|a=#[[#L1|^]] p. 23: Quotation from page 23. |link-id=L1}} consectetur adipisici elit,{{r|n=C2|r=Citation 2|p=92}} sed eiusmod tempor incidunt ut labore et dolore magna aliqua.{{r|n=C1|pp=56, 59|a=#[[#L2|^]] pp. 56, 59: Commentary on page 56 from review.{{r|n=C2|p=70}}|link-id=L2}}{{r|n=C3|r=Citation 3}}

yielding

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua.

However, the role of the outer # in |a= is unclear, it does not appear to handle multiple references to a nested citation and clicking on the list highlights the entire outer citation rather the the specified inner citation. Is there a way to get a true nested citation?. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:43, 2 January 2022 (UTC)

References

Let's distinguish between nested references and sub-references:

When you nest references they are treated as individual references by the underlying MediaWiki Extension:Cite and therefore they can also be highlighted individually. You can nest references up to 5 levels deep (this limit is imposed by MediaWiki's Cite extension, not by {{r}}).

Sub-references are one possible way of utilizing {{r}}'s annotation feature (through |a=), a method to "trick" the underlying Cite extension to append (possibly even multiple times) additional information to references defined elsewhere.

The "hack" you refer to is basically a way to format this additional information in a way so that it looks as if it was a separate reference, possibly even formatted specially, split over multiple lines or indented. However, for the underlying Cite extension, this is still a single reference only, therefore it will highlight the reference with all its sub-references. There is no way to avoid this with the current implementation of Mediawiki. (Cite's long-planned but unfortunately abandoned BookReferencing feature with its proposed extends= attribute would have avoided this by actually treating sub-references as references in their own right, however, since this has not been rolled out the {{r}} template has to work on top of MW's currently existing Cite implementation.)

It is possible to nest references inside sub-references, so that Cite treats them as individual references, however, it will then also list them alongside the other references (that is, not specially formatted and indented under a base reference as with the "hack", so this might not be what you are looking for).

(Regarding the somewhat "hack"ish syntax to make this happen at all, my first goal in implementing it was to keep it as flexible as possible (rather then to enforce one specific format) and to demonstrate that it is possible (at all) to force Cite to output something that looks quite close to actual sub-references. Since I like the output quite a bit, I already started working on a way how to make it simplier for users to set up such sub-references including back&forth links, however, I got distracted and have no time to work on it at present, so this will have to wait some while until I can hopefully continue that work.)

--Matthiaspaul (talk) 03:12, 5 January 2022 (UTC)

By nested citations I mean sub-references to citations, not nested references. That is, I want a <ref>...</ref> with a citation of an entire document, with citations for individual, e.g., pages, sections, rendered below it and indented, with proper links and back links for each nested citation.

What is the reason for #[[#L1|^]] rather than [[#L1|^]] in the hack?? I.e., what are the semantics of that # and where is the help page? Thanks. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:53, 5 January 2022 (UTC)

What you are looking for is the BookReferencing feature of the MediaWiki Extension:Cite, the software which provides those <ref>...</ref> tags. The BookReferencing feature added a new extends= attribute to <ref>...</ref> which does exactly what you want - grouping actual sub-references under a core reference (I'm using the more generic term "reference" rather than "citation" here because <ref>...</ref> can be used for citations and footnotes). This much-wanted feature was developed by the WMDE since 2015, demoed on Beta, and was expected to be rolled out in 2021, but instead has been abandoned in July 2021, unfortunately.

The MediaWiki Extension:Cite currently rolled out in Wikipedia does not support this BookReferencing feature, and since {{r}} is "just" a template layer working on top of MediaWiki's Cite extension, we can only use what is provided by the underlying system. Unfortunately, that version of Extension:Cite does not support grouping of sub-references.

The hack you refer to is {{r}}'s "private method" to format a reference so that it looks a lot like grouped and indented sub-references, but in reality it is only a smart way to apply formatting to a single reference, which (through {{r}}'s annotation parameter |a=) gets combined from multiple fragmentional parts of the definition (that is, the core definition and the various appendages defining pages, etc.). So, although this looks a lot like actual sub-references to readers, it is seen and handled like a single reference by MediaWiki's Extension:Cite, just as if it would have been defined in one piece.

Regarding back & forth links, there is another example further down in the documentation, which - sort of - implements this, but it is not perfect and it is quite cumbersome to set up. (The new version I am working on will further improve the appearance and make it somewhat easier to set up this specific arrangement - but it will take a while because I need a large enough time slot to finish it.)

Regarding the hash marks in the example above, the first # in #[[#L1|^]] is the same # you would use in a numbered list (when used as the first character in a line), the second # is a syntax element preceding an URL fragment so that the link with the text label "^" points to the anchor "L1" in the article. These back & forth links are set up within {{r}} and are completely independent of Extension:Cite (because a template has technically no way to retrieve or even interact with the exact link naming and numbering used by Extension:Cite) - that's why those pseudo-sub-references provided by {{r}} are not (that is, without extends=, cannot be) integrated into the numbering scheme used by the underlying Extension:Cite.

--Matthiaspaul (talk) 19:51, 5 January 2022 (UTC)

Thanks; now that you've explained the first #, it's obvious; I must be blind.

Can you comment on whether and when BookReferencing feature is likely to see the light of day? Thanks. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:21, 7 January 2022 (UTC)

I have no idea, but I would not hold my breath for it. We've waited years for it to be finalized and rolled out. The only thing we can do is to complain about it (on their page, not here, because they won't read it here), and, perhaps, as a community, become smarter in voting in the next Community Wishlist survey... The problem, however, is not their developers but the management, who set wrong priorities (VE).

--Matthiaspaul (talk) 13:03, 8 January 2022 (UTC)

An improved hacky version would be if we could get a lower-alpha ordered list, ideally automatically, but I found no easy way to do it.

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua.

References

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua.

References

—Arthurfragoso (talk) 09:51, 28 April 2022 (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)

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)

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)