User talk:Citation bot

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:DBUG)
Jump to navigation Jump to search

Note that the bot's maintainer and assistants (Thing 1 and Thing 2), can go weeks without logging in to Wikipedia. The code is open source and interested parties are invited to assist with the operation and extension of the bot. Before reporting a bug, please note: Addition of DUPLICATE_xxx= to citation templates by this bot is a feature. When there are two identical parameters in a citation template, the bot renames one to DUPLICATE_xxx=. The bot is pointing out the problem with the template. The solution is to choose one of the two parameters and remove the other one, or to convert it to an appropriate parameter. A 503 error means that the bot is overloaded and you should try again later – wait at least an hour.

Or, for a faster response from the maintainers, submit a pull request with appropriate code fix on GitHub, if you can write the needed code.

Cleanup of date[edit]

new bug
Reported by
Headbomb {t · c · p · b} 22:31, 8 June 2022 (UTC)Reply[reply]
What should happen
We can't proceed until
Feedback from maintainers

Will do, if not book, and if no existing |date=, and id year matches any existing |year=. Now to right the code, and unit tests. AManWithNoPlan (talk) 11:35, 13 June 2022 (UTC)Reply[reply]

Please make this work only with the |volume= parameter, and not |title=.
A date in the title may be genuinely part of the title, e.g. "Hospital opening delayed to August 2023". --BrownHairedGirl (talk) • (contribs) 14:48, 13 June 2022 (UTC)Reply[reply]
I am still not sure how to distinguish dates and Issue numbers/names that are dates. AManWithNoPlan (talk) 18:55, 22 June 2022 (UTC)Reply[reply]
Issue is for issue number, not the issue date/issue name.
  • Smith, J. (2007). "Title". Magazine. No. Summer 2007. p. 23.
should be converted to
  • Smith, J. (Summer 2007). "Title". Magazine. p. 23.{{cite magazine}}: CS1 maint: date and year (link)
Same in cite journal, etc. Headbomb {t · c · p · b} 04:31, 23 June 2022 (UTC)Reply[reply]
Please remove |year= if you add |date= in this case. Izno (talk) 05:15, 23 June 2022 (UTC)Reply[reply]
It we take time to get these right, so I will program in tests before implementing it.AManWithNoPlan (talk) 13:17, 24 June 2022 (UTC)Reply[reply]

Mislabeling Associated Press and Reuters as a "work" rather than an "agency"[edit]

new bug
Reported by
Dawnseeker2000 22:34, 25 June 2022 (UTC)Reply[reply]
What happens
[2] Here, both AP and Reuters are changed from using the "agency" parameter to the "work" parameter.
  1. Usage of the "work" parameter is limited to news sources that are websites, newspapers, journals, or magazines. Agencies follow the formatting style for publishers.
  2. From the initial sentence of our Reuters article: "Reuters (/ˈrɔɪtərz/ (listen)) is an international news agency". See also that our article title is not italicized. That is correct and consistent with ref formatting for news agencies.
  3. From the initial sentence of our Associated Press article: The Associated Press (AP) is an American non-profit news agency. See also that our article title is not italicized. That is correct and consistent with ref formatting for news agencies.
What should happen
Recommend that Associated Press and Reuters be switched to use the "Agency" parameter.
We can't proceed until
Feedback from maintainers

Not a bug. See the template documentation.

Trappist the monk (talk) 23:03, 25 June 2022 (UTC)Reply[reply]

What TMK is referring to is the statement "Do not use for sources published on the agency's own website; e.g. or; instead, use work or publisher". Using the work parameter presents in italics while publisher does not. I wonder why the indifference. I suggest we use the publisher parameter (again, for consistency with "agency" styling). Dawnseeker2000 23:25, 25 June 2022 (UTC)Reply[reply]

I agree with Trappist. In these cases, the news agency is acting as a publisher rather than as an agency. Neutral on whether to use |work= or |publisher=. --BrownHairedGirl (talk) • (contribs) 13:03, 26 June 2022 (UTC)Reply[reply]

When the publisher and work are the same, publisher is not usually used. AManWithNoPlan (talk) 14:29, 26 June 2022 (UTC)Reply[reply]
Associated Press and Reuters are not works though. They are agencies/publishers, and should not be converted to works. Headbomb {t · c · p · b} 15:09, 26 June 2022 (UTC)Reply[reply]
Review the template documentation. Realize accordingly that your comment here is in direct contradiction to your comments above about Cite magazine. Yes, these are the same exact issue. Izno (talk) 16:40, 26 June 2022 (UTC)Reply[reply]
If this was directed at me... which contradiction? Dawnseeker2000 00:03, 27 June 2022 (UTC)Reply[reply]
AP and Reuters are both news agencies, and news works in their own right. When citing the AP or Reuters website directly they are works. When citing a story on another news organisation's website that says that the reporting is from AP or Reuters, then they are acting as an agency. Sideswipe9th (talk) 17:06, 26 June 2022 (UTC)Reply[reply]
When used as the name of a work (for an article directly from the AP web site), it should have |work=AP News or |work=Associated Press News. That is the name they give to that part of their site, that is, the work. It is incorrect to list |work=AP or |work=Associated Press. That is the name of the organization, not the name of their web site, and should appear in |publisher= or |agency= instead. —David Eppstein (talk) 19:51, 26 June 2022 (UTC)Reply[reply]
Yes, that's what I'm saying. News outlets (regardless of media type) are considered publishers Dawnseeker2000 01:18, 27 June 2022 (UTC)Reply[reply]

RfC: Should you use cite web, or cite magazine, or cite news?[edit]

@Sideswipe9th: Please don't hold RfCs in user talk space (the practice of holding RfCs to discuss user conduct ceased some years ago). This matter should be discussed at Help talk:Citation Style 1. --Redrose64 🌹 (talk) 21:29, 1 July 2022 (UTC)Reply[reply]
@Redrose64: I had asked previously where to hold this and there was an even split between this talk page, and the CS1 talk page being the appropriate venue. I'm not opposed to moving it, if it was to be relaunched, so to speak, with the same question, would copy and pasting what has already been discussed and !voted on be acceptable?
I'm also not opposed to using this opportunity to address the concerns raised by both @XOR'easter and David Eppstein:, which may result in a different question being asked however. I'd just like to check what the options are. Sideswipe9th (talk) 21:41, 1 July 2022 (UTC)Reply[reply]
I've moved the whole RfC unchanged, apart from a slight adjustment to the section heading and also omitting the two posts above. --Redrose64 🌹 (talk) 08:14, 2 July 2022 (UTC)Reply[reply]

RFC closed[edit]

The RFC has been closed[3] by @ScottishFinnishRadish:

There is a strong consensus for Citation bot to use {{cite news}} and {{cite magazine}} in cases where online content doesn't appear in a print edition of a publication.

It is helpful to have this community endorsement of Citation bot's good work. This outcome was clearly foreseeable, but it is a relief that the saga is finally over.

However, I remain very sad that so much time and effort was spent in resolving the complaints of the 12 Angry Marvelites who created the drama. Their refusal to listen to more experienced editors led to this vast time-sink, and their aggressive rudeness poisoned the atmosphere. I hope that the 12 Angry Marvelites will reflect on their conduct, and pursue andy further concerns without the groupthink and assumptions of bad faith which characterised their approach to this issue.

And thanks to @Sideswipe9th for their hard work in preparing the RFC. I wish that the RFC had not been needed, but when the 12 Angry Marvelites refused to listen, it was the only way to end the drama. --BrownHairedGirl (talk) • (contribs) 07:35, 2 August 2022 (UTC)Reply[reply]

Thank you all. AManWithNoPlan (talk) 12:52, 3 August 2022 (UTC)Reply[reply]
Some of the people on other side to you seem more experienced with the websites involved with dispute which is more relevant, even though you seem to be more experienced with references. No need to be uncivil, we were acting in good-faith, don't believe we were rude, this is not the place to discuss user conduct. Indagate (talk) 13:34, 3 August 2022 (UTC)Reply[reply]
There is nothing uncivil in pointing out the time wasted by this drama. The rudeness is well-documented, and even extended to falsely accusing the bot of vandalism, an outrageous allegation which was repeated even after the rude Marvelite was pointed to WP:NOTVAND. Not one of the tag-teaming 12 Angry Marvelites objected to that smear, but instead I was attacked for asking for a retraction. And Indagate may not have been actually rude, but it was not civil for Indagate to waste the time of other editors by a silly claim that 9 to 8 amounted to a consensus for their view, and it was not civil for Indagate to falsely claim experience which they actually lacked.
I still hope that the Angry Marvelites may learn from this saga, and raise any further concerns more colegially. BrownHairedGirl (talk) • (contribs) 20:04, 3 August 2022 (UTC)Reply[reply]
@BrownHairedGirl: I have no desire to get into this again, but I'd like to note a few things:
  • This RfC was not a "waste of time" to address our concerns. The lack of consensus in the prior discussion left us with no other option to resolve the dispute, unless you would have preferred that the discussion drag on forever and Citation bot's edits continue to be reverted, or the bot be blocked outright on a large number of pages. I too am deeply saddened that you continue to regard our concerns as petty and insignificant.
  • Just because a group of editors has more "experience" does not mean the opinion of editors with less experience do not matter. We did not refuse to listen to you, we provided very clear counterclaims (magazine websites have different content, etc.) and questioned why Citation bot should continue making these changes despite there being no consensus at the discussion. Do you recall what response we received? "Online magazines are magazines." (Not the point, we're talking about magazine websites.) "There is consensus because most edits are not reverted." (We're talking about consensus in the discussion, not in CB's edits.) And for the record, some of the editors who disagreed with you had comparable levels of experience, so your repeating that you have "more experience" is beginning to feel condescending.
  • Darkwarriorblake is not a "Marvelite". I've almost never seen them pop up on a Marvel-related article, nor are they part of our taskforce.
  • it was not civil for Indagate to waste the time of other editors by a silly claim that 9 to 8 amounted to a consensus for their view – 9 to 8? Really? Unless my counting is significantly off, the participants of the prior discussion were pretty evenly split. If it really were 9 to 8 I wouldn't have called for an RfC, because consensus would have been clear in that case.
  • You continue to admonish us for being rude and uncivil, yet you're once again attacking Indagate, who did nothing wrong. Yes, maybe they shouldn't have claimed experience based on their account age, but that's not the definition of "uncivil", which implies malice. Mind retracting that statement?
To repeat, I do not want another lengthy debate, so I won't reply further. Also, I'd like to thank Sideswipe9th for their efforts as well. But I'll close my comment with this: while it's totally appropriate to reflect on the results of the RfC, do you really think it's appropriate to dance on someone's grave with this patronizing subsection of yours? InfiniteNexus (talk) 05:56, 4 August 2022 (UTC)Reply[reply]
@InfiniteNexus: there is no grave to dance on. Nobody has died or been banned or blocked.
Your choice to reply with absurdly dramatic hyperbole is another reminder of how unpleasant the whole saga was made by the 12 Angry Marvelites. And no, I will not alter my view that making false claims to try to sway a discussion is uncivil. BrownHairedGirl (talk) • (contribs) 07:14, 4 August 2022 (UTC)Reply[reply]

Pages vs Issue vs at vs ...[edit]

new bug
Reported by
SteveMcCluskey (talk) 16:40, 31 July 2022 (UTC)Reply[reply]
Relevant diffs/links
We can't proceed until
Feedback from maintainers

The edit at Aberration_(astronomy) changed the pages= entry to the issue number (e.g., A91), removing the page range (e.g. 1-6) of the article. This happened several times. I recently corrected the pages= entries.

You're actually reintroducing errors the bot is fixing (full proper fix is here, there were some GIGO issues). A&A and similar journals use an 'article ID' instead of a page number. This is what goes in |page= and how people cite these journals. There are no issue numbers for those. Headbomb {t · c · p · b} 17:07, 31 July 2022 (UTC)Reply[reply]
I'm puzzled by this usage. There are clearly page numbers in the pdf version of the article; where should they be provided if not in the page(s)= entry of the citation template. The article ID seems analogous to an issue number. Could you point me to appropriate reference supporting this strange usage of the citation template. --SteveMcCluskey (talk) 18:08, 31 July 2022 (UTC)Reply[reply]
OK, I see that you're using the page= value to place the ArticleID without parentheses, which are used for issue numbers. It's a bit of a kludge but it reproduces the style used in AandA. However, it leaves no place for the page numbers (which this historian of science finds standard for a complete citation). I'm not going to make a big deal of it. --SteveMcCluskey (talk) 18:31, 31 July 2022 (UTC)Reply[reply]
So when I tag those citations with {{Page needed}}, what is the suggested remedy? SamuelRiv (talk) 18:51, 31 July 2022 (UTC)Reply[reply]
Don't misuse parameters to hold something that they are not intended to hold. An article number is not an in-source location so |page=, |pages=, and |at= are not the right place for an article number. cs1|2 does not have any support for article numbers. I think that there has been some discussion at Help talk:Citation Style 1 but never to the point of action. Quite often I see article numbers in |number= (an alias of |issue=) which, really, is also incorrect. I suppose that if you must include an article number |number= is the best place for it pending some decision to add support for article numbers – but don't be surprised when someone like me comes along and removes it.
Trappist the monk (talk) 19:07, 31 July 2022 (UTC)Reply[reply]
Perhaps use the |id= parameter. --Redrose64 🌹 (talk) 22:41, 31 July 2022 (UTC)Reply[reply]
|id= is for bibliographic identifiers like {{Zbl}} etc... (when there aren't nativaly supported), not the article number. |page= is perfectly fine for it, thought if you want to be an überpedant, |at= is probably what you're looking for. Headbomb {t · c · p · b} 22:46, 31 July 2022 (UTC)Reply[reply]
Trappist has already stamped on |at=. I'm trying to find a parameter which would not be misused. --Redrose64 🌹 (talk) 23:33, 31 July 2022 (UTC)Reply[reply]
I think Trappist is wrong. For journals that identify articles by article numbers rather than by page numbers, the article number must be included in the citation, in the position that the page numbers would go for page-number-using journals, and page= or at= are the only ways to put it there. id= is no good because it puts the key article-identifying information in the wrong part of the citation. —David Eppstein (talk) 23:50, 31 July 2022 (UTC)Reply[reply]
Trappist is wrong indeed. Headbomb {t · c · p · b} 00:15, 1 August 2022 (UTC)Reply[reply]
I've been using |id= for press release numbers but reading this I think that may have been wrong. Perhaps I should have been using |number= instead, but there is no documentation to support this. Hawkeye7 (discuss) 01:26, 1 August 2022 (UTC)Reply[reply]
Yes. Article numbers go in the same slot as page numbers; the journals themselves even do it that way (Philosophical Transactions of the Royal Society springs to mind as an example that I've seen recently). XOR'easter (talk) 16:09, 1 August 2022 (UTC)Reply[reply]
I'm pleased to see that I wasn't the only editor disturbed by changes involving article IDs. Articles with article IDs also have page numbers within the article. There should be a separate place for both within the citation template. It's beyond my abilities but those involved in maintaining the citation templates should be asked to deal with this new citation style, which seems to be proliferating in the science journals. --SteveMcCluskey (talk) 21:06, 1 August 2022 (UTC)Reply[reply]
Standard practice is to use brackets |page=A9 [17] if you want to refer to a specific page/page range. Headbomb {t · c · p · b} 21:10, 1 August 2022 (UTC)Reply[reply]
Another convention I've seen (working better when the article numbers are short) is to use artnum:firstpage–artnum:lastpage as the range of pages, so Headbomb's example would become |pages=A9:1–A9:17. That's how they're numbered by LIPIcs (an open-access publisher of many computer science conference proceedings), for instance. —David Eppstein (talk) 07:22, 4 August 2022 (UTC)Reply[reply]

Shouldn't NYT render as newspaper, and be linked, instead of work (with no link)? (bug or improvement?)[edit]

new bug
Reported by
Guarapiranga  01:48, 1 August 2022 (UTC)Reply[reply]
What happens
When generating citations, NYT is classed as work instead of newspaper (e.g.[1])
What should happen
We can't proceed until
Feedback from maintainers


  1. ^ Sorkin, Suzanne Kapner With Andrew Ross (2001-09-24). "Deutsche Bank To Buy Scudder In Deal Worth $2.5 Billion". The New York Times. ISSN 0362-4331. Retrieved 2022-08-01.
  2. ^ Sorkin, Suzanne Kapner With Andrew Ross (2001-09-24). "Deutsche Bank To Buy Scudder In Deal Worth $2.5 Billion". The New York Times. ISSN 0362-4331. Retrieved 2022-08-01.

Whether to link a work is a page-specific choice. As for work versus newspaper, |work= is (effectively) an alias of the other without possibly mis-stating what the value of the parameter actually is. In CS1, it is sufficient. (In CS2, it would require a bit more work than to use |work= in general.) --Izno (talk) 04:14, 1 August 2022 (UTC)Reply[reply]

I see.
Whether to link a work is a page-specific choice.
What does that choice typically depend on? Guarapiranga  07:50, 1 August 2022 (UTC)Reply[reply]
Couldn't say since I feel no inclination to do so in my work, but either way it's not an appropriate bot action. :) Izno (talk) 15:54, 1 August 2022 (UTC)Reply[reply]
Can you point me to any policy on this, Izno? I couldn't find it on WP:REF. — Guarapiranga  05:57, 2 August 2022 (UTC)Reply[reply]
WP:CITEVAR is the policy. Headbomb {t · c · p · b} 05:59, 2 August 2022 (UTC)Reply[reply]
"this"? That it is a per-page matter? WP:DUPLINK is a good start; Citations stand alone in their usage, so there is no problem with repeating the same link in many citations within an article; e.g. |work=The Guardian. However, this is in the overall context of "don't make duplicate links", so editors should have local control over which works to link in citations, and whether to link them in multiple or not at all. Izno (talk) 06:01, 2 August 2022 (UTC)Reply[reply]
There's also collected bibliographies (structured lists of works cited, usually only the first instance is linked) vs unstructured lists (where often all instances are linked). The bot can't distinguish between these. Headbomb {t · c · p · b} 06:05, 2 August 2022 (UTC)Reply[reply]
editors should have local control over which works to link in citations
Absolutely, but is there a downside to CITEBOT suggesting notable newspapers, magazines, news channels, etc, to be linked by default? — Guarapiranga  09:20, 2 August 2022 (UTC)Reply[reply]
Violations of WP:CITEVAR and some of the worse infighting you'll see on Wikipedia, with bot blocks, and weeks/months of wasted time on RFCs. Headbomb {t · c · p · b} 12:00, 2 August 2022 (UTC)Reply[reply]

Wikipedia:Wikipedia Signpost/2022-08-01/Tips and tricks[edit]

Just a heads up that my little handy dandy guide on Citation bot finally got in the Signpost, as intended years ago. Feel free to leave a comment (or make suggestions for other guides on different topics). Headbomb {t · c · p · b} 20:04, 1 August 2022 (UTC)Reply[reply]

Thank you. AManWithNoPlan (talk) 00:05, 2 August 2022 (UTC)Reply[reply]
Just read it, and it is good. AManWithNoPlan (talk) 00:14, 2 August 2022 (UTC)Reply[reply]
Good work, @Headbomb. And it's probably just as well that this fine guide did not appear sooner, 'cos until Citation bot got a massive amount of extra capacity a few months ago, the result of the extra attempts to use CB would ave been a lot of frustrated editors as requests timed out. BrownHairedGirl (talk) • (contribs) 07:09, 2 August 2022 (UTC)Reply[reply]
Thanks for the words, though Wikipedia talk:Wikipedia Signpost/2022-08-01/Tips and tricks is probably the place to centralize discussion about the article. Headbomb {t · c · p · b} 07:35, 2 August 2022 (UTC)Reply[reply]

Citation bot tries to fetch from known dead URLs[edit]

new bug
Reported by
Guy Harris (talk) 00:53, 3 August 2022 (UTC)Reply[reply]
What happens
If Citation Bot sees a template with archive-url= and a url-status other than live, it tries fetching using the url= value, even though the url-status indicates that it's not working.
What should happen
Unless there's url-status=live, if there's an archive-url parameter, it shouldn't bother looking at what url= specifies.
Relevant diffs/links
Replication instructions
Run Citation Bot in thorough mode on VAX, and note that there is a "could not resolve" message for, the reference for which has an archive-url link and does not have url-status=live. Other pages have gotten timeouts for dead URLs with archive-url and no url-status=live.
We can't proceed until
Feedback from maintainers

The citation that matches that URL has no url-status flag set. Neither does the the other citation to Do you get the same error if you set |url-status=dead? Sideswipe9th (talk) 01:01, 3 August 2022 (UTC)Reply[reply]
First not flagging a url as live does not mean the url is dead. Second, even if it was flagged dead, websites often from back to life, so in thourough mode, it should definitely check the url if it can. Headbomb {t · c · p · b} 01:41, 3 August 2022 (UTC)Reply[reply]
"First not flagging a url as live does not mean the url is dead" The documentation for those parameters is not of the highest quality.
Help:Citation Style 1 says:
  • url-status: To change the order with the title retaining the original link and the archive linked at the end, set |url-status=live
When the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable, setting |url-status=unfit or |url-status=usurped suppresses display of the original URL (but |url= and |archive-url= are still required).
and Template:Cite web says:
By default, if "archive-url" is used, the parameter |url-status=dead is assumed and the resulting main link is to the archived version:
and Template:Citation Style documentation/url says of url-status:
this optional parameter is ignored if archive-url is not set. If omitted, or with null value, the default value is |url-status=dead.
(and also mentions a "deviated" value for url-status).
So either not flagging a url as live does mean it's dead, if there's an archive-url parameter, or the documentation needs to be fixed to indicate that omitting url-status isn't the same as saying url-status=dead. Guy Harris (talk) 02:05, 3 August 2022 (UTC)Reply[reply]
"Second, even if it was flagged dead, websites often from back to life, so in thourough mode, it should definitely check the url if it can." ...but not complain if the check fails, because it was warned that it's (probably) dead). Guy Harris (talk) 02:09, 3 August 2022 (UTC)Reply[reply]
So either not flagging a url as live does mean it's dead No it doesn't. It's an assumption the template makes as far as the presentation of links go. It does not mean the URL is dead. Plenty of people simply archive links preemptively, but don't bother as flagging the url as live, mostly because it's rather pointless to do so.
...but not complain if the check fails The bot doesn't a complain about it, it reports that the check failed.
> Could not resolve URL
The message is in gray, because it's not a very important thing to report. Unlike messages that are in red/orange/other colors. ce Headbomb {t · c · p · b} 03:00, 3 August 2022 (UTC)Reply[reply]

Postscript again[edit]

new bug
Reported by
– Arms & Hearts (talk) 16:45, 5 August 2022 (UTC)Reply[reply]
What happens
Citation bot removes a necessary non-breaking space from the |postscript= parameter in {{cite journal}} and {{cite web}}
Relevant diffs/links,_Jews,_and_Us&diff=1102312419&oldid=1098444133
We can't proceed until
Feedback from maintainers

This was marked as fixed in February 2020 – either that was in error or it's subsequently been broken again. – Arms & Hearts (talk) 16:45, 5 August 2022 (UTC)Reply[reply]

|postscript= specifies the citation's terminal character. For cs1 templates, the default character is a dot; for cs2 templates, the default is no terminal punctuation. When the value assigned to |postscript= has more than one character, Module:Citation/CS1 emits a CS1 maint: postscript message and adds the article to Category:CS1 maint: postscript. At Whites, Jews, and Us § External links, both cs1 templates have |postscript= – which Module:Citation/CS1 sees as 7 characters. The exception to this one-character limit is the keyword none which suppresses the normal cs1 terminal dot (not allowed in cs2 templates because redundant). Consider writing:
{{cite ... |postscript=none}}&nbsp;– <descriptive text>
for cs2 templates:
{{citation ... }}&nbsp;– <descriptive text>
Trappist the monk (talk) 19:01, 5 August 2022 (UTC)Reply[reply]
Thanks Trappist the monk, now fixed in the article as per. I see that the documentation for {{cite journal}} and {{cite web}} both say Additional text, or templates that render more than a single terminating punctuation character, will generate a maintenance message, but that doesn't seem to have happened here. – Arms & Hearts (talk) 12:17, 6 August 2022 (UTC)Reply[reply]
Are you sure? When I look at this citation in your revert of the bot edit, I see both maintenance messages. Remember that maintenance messages are hidden by default. Editors who wish to see the maint messages must enable them (see Help:CS1 errors § Controlling error message display).
You came to this discussion with the complaint that the bot [removed] a necessary non-breaking space yet in this edit you did the same thing?
Trappist the monk (talk) 13:13, 6 August 2022 (UTC)Reply[reply]
I didn't realise maintenance messages were opt-in – from the documentation I assumed it would be like the red "Text 'Foo' ignored" and similar messages that I see without having to enable anything. Re the space, it only needed to be a non-breaking space while in the postscript parameter, as a leading space is ignored otherwise. If it's not in the template a normal space is fine (but per MOS:DASH en dashes still need to be spaced). – Arms & Hearts (talk) 14:19, 6 August 2022 (UTC)Reply[reply]
cs1|2 emits preview messaging in the preview-warning box at the top of a previewed page which advertises the existence of cs1|2 error and maintenance messages and links to the instructions that describe how to display or hide those messages.
The Wikipedia:Manual of Style § Punctuating a sentence (em or en dashes) heading in MOS:DASH says (in part):
Ideally, use a non-breaking space before the en dash, which prevents the en dash from occurring at the beginning of a line (markup: {{spaced ndash}} or {{snd}} or &nbsp;&ndash;)
There is no reason to believe that a citation in Whites, Jews, and Us § External links won't wrap at a place that would place the en dash at the beginning of a new line; where a wrap occurs depends on user screen size, window size, font size, zoom level, ...
Trappist the monk (talk) 14:57, 6 August 2022 (UTC)Reply[reply]
There are sometimes good reasons not to use non-breaking spaces, i.e. to minimise potentially confusing and easily breakable code for the benefit of newer editors using the source editor. I assume that's why that bit of the guideline's framed as it is ("ideally") and isn't that commonly adhered to. But no objection to using them in this case. – Arms & Hearts (talk) 15:42, 6 August 2022 (UTC)Reply[reply]

A barnstar for you![edit]

Brilliant Idea Barnstar Hires.png The Brilliant Idea Barnstar
This bot is great! Andre🚐 02:47, 8 August 2022 (UTC)Reply[reply]

Suggestion: convert Google books URLs to GBurl templates[edit]

Reported by
RDBrown (talk) 10:04, 11 August 2022 (UTC)Reply[reply]
What happens
Google books URLs have changed
We can't proceed until
Feedback from maintainers

Instead of modifying Google books URLs, use the GBurl template where the search parameters are encompassed by the template. This change may need an RFC. Possibly the Citer tool (python) may provide more documentation on the parameters of the Query part of the URL, for which there doesn't seem to be easily findable documentation. In *Template.php:expand_by_google_books_inner* the current code doesn't seem to cope with the munged title now being part of the string, so that may be worth enhancing.

      if (preg_match("~^https?://www\.google\.(?:[^\./]+)/books/edition/_/(.+)$~", $url, $matches)) {

Here's some perl snippets since I'm not PHP literate.

use URI;
use URI::Split qw(uri_split uri_join);

while (<>) {
    next if /^$/;
    if (/^\s*#/) {
	print $_, "\n";
    my($uri) = URI->new($_);
    my($sch, $aut, $pth, $qry, $frg) = uri_split($uri);
    if (defined($sch) && ($sch eq 'http' || $sch eq 'https')
    && defined($aut) && defined($pth)) {
	substr($aut, -3, 3) = '' if substr($aut, -3) eq ':80';
	if ($aut =~ /^www\.google\.c(?:a|o(?:m|m\.au|\.uk|\.in))$/
	&& $pth =~ m|^/books/edition/[^/]+/([-A-Za-z0-9_]{12})$|) {
	    my($gb_arg) = $1;
	    foreach my $gb_restrict (split('&', $qry)) {
		if ($gb_restrict =~ /^(pg|dq)=/) {
		    if (substr($gb_restrict, 0, 5) eq 'pg=PA') {
			$gb_arg .= '|p=' . substr($gb_restrict, 5);
		    else {
			$gb_arg .= '|' . $gb_restrict;
		elsif ($gb_restrict =~ /^bsq=(.+)/) {
		    $gb_arg .= '|dq=' . $1;
		# Safe to skip: hl= (Normally en), gbpv=
		# printsec= - skip only if there's a pg=
		# Shouldn't convert if there's anything else?
	    $template = "{{GBurl|$gb_arg}}";
Example URLs Provincial'Barnstead%20charter'%20Provincial&pg=PA419&printsec=frontcover


Caps: The Newspaper for IT Leaders[edit]

new bug
Reported by
Headbomb {t · c · p · b} 10:58, 11 August 2022 (UTC)Reply[reply]
What should happen
We can't proceed until
Feedback from maintainers