Jump to content

Help talk:Citation Style 1/Archive 92

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 85←Archive 90Archive 91Archive 92Archive 93Archive 94Archive 95

Best practices for a full citation with no author, when linked by shortened footnotes

Resolved
 – The help page now transcludes the advice from Template:Harvard citation documentation and includes two examples informed by the discussions below. Many thanks for the assistance and happy Thanksgiving, Rjjiii (talk) 08:45, 23 November 2023 (UTC)

I have a question about a help page which is directly giving advice about the CS1/CS2 templates. Are any of the no-author styles explained at H:SFN, misusing a parameter? The section at Help:Shortened footnotes#No author reads:

Some sources do not have a single author with a last name, such as a magazine article or a report from a government institution. Options include:
  • For a newspaper or periodical, use the name of the publication and the date, or set the author parameter to "publication name staff".[i]
  • For a publication by an institution, use the name of the institution.
  • Some style guides recommend using the title of the article (title-date).
  • Other style guides recommend using "Anonymous" or "Anon."
  1. ^ Setting the author parameter to something solves the problem of having to set the "ref=" parameter to something other than that which is automatically generated.

This seems to contradict the template documentation, but I have seen a lot of people create citations using the |author= field this way. Regards, Rjjiii (talk) 22:44, 22 November 2023 (UTC)

You've gone to the trouble of quoting H:SFN which you then claim seems to contradict the template documentation but you fail to specify or quote that conflicting documentation. Which template? Which documentation?
—Trappist the monk (talk) 23:03, 22 November 2023 (UTC)
@Trappist the monk: Valid point, Template:Cite book/doc gives this example: |author=<!--Staff writer(s); no by-line.--> and explains the author parameter as so: this parameter is used to hold the name of an organizational author (e.g. a committee) or the complete name (first and last) of a single person; for the latter, prefer the use of |first= and |last=. This parameter should never hold the names of more than one author. Template:Cite news/doc and Template:Cite journal/doc contain the same text. Rjjiii (talk) 23:16, 22 November 2023 (UTC)
I changed the example in Template:Cite book/doc § Usage to match the recommendation at Help:Citation Style 1 § Authors.
Why do you think there is a contradiction? All that the cs1|2 template doc says is use real names, for humans prefer |last=/ |first= pairs for each human author. The |author=<!--Not stated--> is merely a recommendation to prevent future en.wiki editors from wasting their time searching for author(s) who have not been named. I don't see any of that as a contradiction.
I do think that making up names for any of the |author= aliases (|author=Anonymous etc) is wrong because that attributes the work to an author who appears to be named 'Anonymous'. Similarly, |author=publication name staff is just as bad. For periodicals, I think that the best solution for use with {{sfn}} is to set |ref={{sfnref|''<periodical name>''|<date> and {{sfn|''<periodical name>''|<date>}}
—Trappist the monk (talk) 23:45, 22 November 2023 (UTC)
Surely the advice should be to setup the |ref= field appropriately rather than misusing |author=. Especially when it duplicates publisher, and doubly so when it comes to constructs such as title/year. -- LCU ActivelyDisinterested «@» °∆t° 23:34, 22 November 2023 (UTC)
Yes, and this poor documentation probably explains why I keep running into redundant junk like |author=NYT staff, or even worse |author=The New York Times|work=The New York Times or |author=Museum of Modern Art|publisher=Museum of Modern Art. The material at H:SFN is clearly wrong, or at least badly misleading. You might need to use a short footnote that read something like "Museum of Modern Art (2023)" when there is no specified author, but the way to template this is to use |ref={{harvid|Museum of Modern Art|2023}} in the main citation, not to do a bogus |author=Museum of Modern Art that is redundant with |publisher=Museum of Modern Art. This can probably be resolved by editing H:SFN and the docs of Template:Sfn to include specific examples of this sort, and to explicitly say not to abuse the |author= or |last= parameter to kluge this. PS: {{harvid}} has been moved to {{SfnRef}}, and it may be preferable to update the mentions of {{harvid}} to use the current actual name of the template.  — SMcCandlish ☏ ¢ 😼  23:42, 22 November 2023 (UTC)
+1 -- LCU ActivelyDisinterested «@» °∆t° 23:50, 22 November 2023 (UTC)
I copied the text by Charlie Gillingham from Template:sfn/doc to Help:Shortened footnotes, changing "harvid" to "sfnref", which already suggested using |ref=.[1] And regarding the question of why I saw the language as contradictory, I was saying that advice to use the title of the work or a description of the author (at H:SFN) seemed to contradict the advice to use a person or organization's name (at Template:Cite book/doc). I was uncertain, so I asked. Rjjiii (ii) (talk) 00:53, 23 November 2023 (UTC)
Also, thanks all for the input, Rjjiii (ii) (talk) 00:54, 23 November 2023 (UTC)
Keeping in mind that {{sfn}} should be short, and this is all about convenience for editors (i.e., not users), I think the |ref= should be encouraged to be short as well, so rather than |ref={{harvid|Museum of Modern Art|2023}}, it should be |ref={{harvid|MMA|2023}} which will very likely be unique among refs on the page (and if not, there are alternatives). Mathglot (talk) 01:14, 23 November 2023 (UTC)
I disagree. Initialisms are inherently obscure so in general should be avoided. But, surely, if you are going to use an initialism, and the source has a commonly used initialism, use the source's initialism, not one that you made up or is used by some other organization. In your example, if you must use an initialism it should be 'MoMA' not 'MMA' (commonly used for Mixed Martial Arts}. For the avoidance of doubt, both long- and short-form citations should use the same name.
—Trappist the monk (talk) 01:25, 23 November 2023 (UTC)
Yep.  — SMcCandlish ☏ ¢ 😼  02:16, 23 November 2023 (UTC)
The example from the {{sfn}} doc page includes a generic "BGI" initialization. I've replaced that on H:SFN with a "MoMA" shortened footnote.[2] I haven't changed anything on the template documentation. Rjjiii (ii) (talk) 02:42, 23 November 2023 (UTC)
Unnecessary pile-on support for this statement. Anything used in the {{sfnref}} should either appear verbatim in the full citation or be listed in a "(Cited as Short Name)" parenthetical immediately following the full citation. Folly Mox (talk) 05:35, 23 November 2023 (UTC)
And by the way, for those who are talking about "modify the sfn doc" (which I generally agree would be a good thing) it's a little hard to find; it's at Template:Citation Style documentation/author. Mathglot (talk) 01:44, 23 November 2023 (UTC)
@Mathglot: Thanks for helping out. I see you've transcluded the text from Template:Harvard citation documentation#No author name in citation template. That seems easier to maintain. Would it be wise then, to transclude the whole thing, and use whichever example is best on that page? Rjjiii (talk) 04:03, 23 November 2023 (UTC)
Also, what do you mean about "the table column presentation is messed up in this one"? I see a 2x2 grid in both? Rjjiii (talk) 04:06, 23 November 2023 (UTC)
Yes, it's 2x2, but left col is 90% of page width on a computer monitor; are you using only mobile to view it? Maybe I should verify with some other browsers, in case it's just me? Mathglot (talk) 05:07, 23 November 2023 (UTC)
Works now; your "3rd time" fix did it. Must've been the url. I've seen that issue before, and I forget how I fixed it, but there's a way. In the meantime, the shorter url works fine. Mathglot (talk) 05:24, 23 November 2023 (UTC)
@Mathglot: thanks for the explanation! I tested the mobile skin and both desktop skins but only on Firefox. Chrome keeps the URLs as one line and Firefox breaks them at the slashes. As soon as I read your "left col is 90%", I realized how I goofed. I've run into this problem before and totally forgot about it. With a smaller URL and a space before the parameter, it now looks fine on desktop Chrome, mobile Chrome, mobile Safari, Edge, the android app, and some niche browsers. Thanks again, Rjjiii (talk) 05:47, 23 November 2023 (UTC)
Guess I'm a niche browser person; I use Vivaldi almost exclusively, others on mobile, or for testing or special purposes. Mathglot (talk) 06:35, 23 November 2023 (UTC)
As far as transcluding the example as well: excerpting from a Template that can have params is tricky, because {{Excerpt}} doesn't pass params; so I conservatively excerpted only the top part with the intro paragraph and bullet list, because I could easily see that there were no template params like {{{1|}}}; the markup code below it was denser, and I didn't want to risk a mistake by transcluding it if it used params. If it doesn't, that should be excerptable as well. Mathglot (talk) 05:11, 23 November 2023 (UTC)

Ordering of full citations

If an article is using shortened references, that means a full list of sources appears in alphabetical order according to the first element; the only fields which can be first in a CS1 template are |author=/|last= or |editor-last= I believe. If there is a |ref={{harvid|MoMA|2023}} then a reader should be able to find MoMA accordingly amongst other M-names and so the first element should include whatever tag the reader will use to find the source in an alphabetic list.

For the curious, here's the CMoS:

If a publication issued by an organization, association, or corporation carries no personal author’s name on the title page, the organization may be listed as author in the reference list, even if it is also given as publisher. To facilitate shorter parenthetical text citations, the organization may be listed under an abbreviation, in which case the entry must be alphabetized under that abbreviation (rather than the spelled-out name) in the reference list.

Umimmak (talk) 06:37, 23 November 2023 (UTC)

Wikipedia isn't bound by a single thing CMoS says. Our own material at WP:CITE (including WP:SFN) requires neither shortened footnotes (much less ones in CMoS style in particular) nor an alphabetical list of sources. It generally makes sense to provide one, if an article is using shortened footnotes, but putting a {{cite web |publisher=[[Museum of Modern Art|MoMA]] |...}} in alphabetical order under "MoMA" is perfectly fine. If some reader's head would just explode upon encountering this, they are not competent to be reading our material in the first place. And no one reads lists of citations like a novel. They get to a citation by clicking on a link to it. If for some reason they did not but are manually hunting around for a MoMA source in a list of sources (why?), all they have to do is Ctrl-F MoMA Enter (or on a Mac Cmd-F MoMA Enter). If this still just somehow doesn't compute for someone on the editorial side, they can do the source list entry as * MoMA: {{cite web |publisher=[[Museum of Modern Art|MoMA]] |...}} (though I think other editors would later remove the leading "MoMA: " as extraneous and silly, treating our readers as if they had brain damage). Nothing said above is any excuse for doing a bogus |author=MoMA.  — SMcCandlish ☏ ¢ 😼  07:18, 23 November 2023 (UTC)
The tone of your comment was needlessly rude…
We aren’t bound by Chicago, obviously, but I think it’s worth seeing what other style guides do in similar situations. Why alphabetize anything if the links take an online reader directly to the source or they can use a search function? People sometimes print out articles, the Creative Commons license allows materials to be used elsewhere which might not have as robust links, links can also be be broken for a variety of reasons and having sources in an order which makes intuitive sense to the reader might be an asset that the editors of some articles might desire.
If there is no author, the first part of the citation would be the title; MLA uses an abbreviated title in its parentheticals when there is no author, and this is another option if it’s really that bad to repeat information. That way sources can be still sorted alphabetically by their first element and by whatever appears in the shortened citation. Umimmak (talk) 08:02, 23 November 2023 (UTC)
I already said it was probably a good idea to alphabetize them. If you insist on having the first element on the line be the name by which it is alphabetized, I already provided you a way to do that without fudging citatation template parameters, though there is no reason in the first place to suppose that our readers are so dense they can't understand that an entry with no author which is alphabetized in the Ms between Michaels and Munster is under MoMA, the publisher name.  — SMcCandlish ☏ ¢ 😼  08:14, 23 November 2023 (UTC)
Way off topic: This ship may have sailed, but {{harvtxt|ref=none|Last|YYYY}}.  will create exactly the citation format for the bibliography when given the same parameters as {{sfnref}}.[1] The citation templates could generate this when fed sfnrefs, but I don't know if it's worth the effort. It also won't be highlighted from the pinball links.

References

  1. ^ SSAC 2023.
  • SSAC (2023). "Black History Month Profile: Leroy Chollet (Loyola)". SSAC Sports. Montgomery, Alabama: Southern States Athletic Conference. February 27, 2023. Archived from the original on March 29, 2023. Retrieved March 29, 2023.
Rjjiii (talk) 08:40, 23 November 2023 (UTC)
Simpler to just do plain text:
if the goal of this stuff is just to ensure that the citation line-item begins with the string it is alphabetized by. Which, again, is not a requirement that we have; it's just something a few editors want to have happen for reasons I find non-compelling since it's obvious in an alpha-ordered list of such sources that this one is alphabetized under "SSAC Sports". If this is just for editorial benefit, Mathglot's approach below gets the job done, though would be simpler to type and easier to read as <!--Aron 1962--> than <!--{{sfn|Aron|1962|p=}}-->.  — SMcCandlish ☏ ¢ 😼  09:29, 23 November 2023 (UTC)
True, and maybe I'm taking ease of use to a fault, but what I want to do is kill two birds with one stone, demonstrating the alphabetization element first, as well as having a copy-paste element readily available that makes use of {{sfn}} as brainless as possible. There are *so* many errors with it (as ActivelyDisinterested can attest), that anything I can do to assure the correct {{sfn}} formulation is used, is a step in the right direction, and worth the (minimal) extra effort in typing out a few more characters. That said, SMcC's (how do you abbreviate a name like that, anyway?) version does the job. Mathglot (talk) 09:43, 23 November 2023 (UTC)
Fair enough. I guess the articles I'm shepherding that use one form or another of shortened references haven't had a problem of "drive-by" users making mucked up sfn instances with wrong author names or dates in them, so I'd never had a "show them how to do the citation right" need. PS: Yes, SMcC or S.McC. or S. McC. would be pretty typical. My pool team has two Johns, and we call them John McN. and John P. in texts. If the latter had been Irish, he might have ended up compressed to John O'P. :-)  — SMcCandlish ☏ ¢ 😼  09:55, 23 November 2023 (UTC)
Just to say there are so many errors with it because it doesn't appear that the error category has ever been cleared down before. New errors are generally caused by inexperienced editors not understanding how referencing should be done. -- LCU ActivelyDisinterested «@» °∆t° 12:07, 23 November 2023 (UTC)

The alphabetization of sources in a "Works cited" or "Bibliography" section is mostly for the user, but has benefits for the editor wishing to expand the article and reuse the citations as well. Unfortunately, it's not always easy to find the "alphabetization item", which might be last1, last, author, surname, editor1-last or something from |ref=, and which might be placed anywhere in the template... tick, tock; .... tick, tock; ... tick, tock; ... Have you found it, yet? I finally got tired of this, and to make it easier for myself on subsequent edits, and for other editors, I hit upon the solution I used in Liberation of France#Works_cited (edit ). It makes it easier for editors, and has no effect on readers. Mathglot (talk) 09:12, 23 November 2023 (UTC)

An easier solution is to include alphabetical breaks <!-- A --> etc. As can be seen in the Bibliography of Historiography of Christianization of the Roman Empire. Any editors can just search the correct string, and it's very simple and easy to understand for new editors. -- LCU ActivelyDisinterested «@» °∆t° 12:12, 23 November 2023 (UTC)
@ActivelyDisinterested Naively done as there causes a WP:LISTGAP. Please feel free to correct it as you see fit. Izno (talk) 19:07, 25 November 2023 (UTC)
They're not causing LISTGAP at Historiography of Christianization of the Roman Empire, maybe that only applies if you haven't used {{refbegin}}/{{refend}}. -- LCU ActivelyDisinterested «@» °∆t° 19:13, 25 November 2023 (UTC)
ActivelyDisinterested, yes, actually, the use there is a LISTGAP problem. A comment on its own line will break the lists, which is what LISTGAP concerns itself with. IznoPublic (talk) 03:10, 26 November 2023 (UTC)
Are you suggest that a screen read would want to read through the hundred+ cites in that article as if the where a list? Maybe as a sleep aid. And if they did the list would be sectioned alphabetically. This isn't four items in an infobox. -- LCU ActivelyDisinterested «@» °∆t° 12:14, 26 November 2023 (UTC)
@ActivelyDisinterested no, they don't, and that's the problem. What they will hear is "list of N/26 items, would you like to listen?" times 26 as they attempt to come to the end of the section. This is categorically worse for navigation. Moreover, they will have no idea that each is separated by a letter, the only information they get is "list of N/26 items" before diving into each. Izno (talk) 21:41, 26 November 2023 (UTC)

I've seen that people make good use of Category:CS1 maint: PMC format. It would be nice to have a maintenance category for citations which contain a PMC ID but also a link from the url parameter: such links are often subject to link rot and need updating or removing. This could later be extended to other green OA IDs if they auto-link. Nemo 07:08, 28 November 2023 (UTC)

Date format for CITEREF

Hello! Need help again. In the Russian Wikipedia, we replace all dates with the ISO format (we display them in a human-readable way in the desired language through another module) so that those who copy articles and sources from us do not have to fool around with unreadable and unprocessable dates (English, Russian, Spanish or any other). But I now noticed that CITEREF cannot take the year from such a date (YYYY-MM-DD). It can be fixed? :) Iniquity (talk) 16:21, 27 November 2023 (UTC)

Umm, not true:
{{cite book |title=Title |last=Green |first=EB |date=2023-11-27}}
Green, EB (2023-11-27). Title.
'"`UNIQ--templatestyles-0000002A-QINU`"'<cite id="CITEREFGreen2023" class="citation book cs1">Green, EB (2023-11-27). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2023-11-27&rft.aulast=Green&rft.aufirst=EB&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+92" class="Z3988"></span>
Show me an example of a cs1|2 template at ru.wiki that does not correctly include the year portion of |date= in the template's id= attribute.
—Trappist the monk (talk) 16:34, 27 November 2023 (UTC)
Oh, thanks for the example. This turns out to be an error that the module does not support YYYY-MM. It seemed to me that the module supported the whole ISO :( Iniquity (talk) 16:41, 27 November 2023 (UTC)
This is not an error. The issue is that, at least in English, YYYY-MM can be ambiguous with YYYY-YY, indicating a range. Izno (talk) 16:59, 27 November 2023 (UTC)
Yes, I remembered that old discussion, thanks! I'll have to fix this locally somehow :( Iniquity (talk) 17:01, 27 November 2023 (UTC)
I have fixed YYYY-MM DATE for ruwiki, can you check plz, is it right way? :) [3] Iniquity (talk) 21:35, 28 November 2023 (UTC)
Looks like the change is probably correct. You've tested your code, right? You might want to fix the comment at line 505 (remove reference to 'day').
—Trappist the monk (talk) 22:59, 28 November 2023 (UTC)
Thank you very much for checking! I will fix it :) Iniquity (talk) 01:42, 30 November 2023 (UTC)

New CS1 error for "Cite journal"

{{Cite journal}} now shows a Cs1 error wherever a source is templated according to it but does not actually cite a journal title. Can this be fixed by editing the template or fixed en masse by a bot in all use cases? Æo (talk) 17:53, 28 November 2023 (UTC)

No, a bot is not able to fix all of these cases. There may be some groups with similar patterns that can be fixed by editors using AWB. The help text explains how to fix each erroneous template transclusion. – Jonesey95 (talk) 18:42, 28 November 2023 (UTC)

Aliase for 'Author'

Hello! I need to set an alias for the "author" parameter, but adding ['Author'] = 'автор', to the configuration not works. Iniquity (talk) 21:38, 28 November 2023 (UTC)

In ~/Configuration, remove ['Author'] = 'автор' and add 'автор#' to ['AuthorList-Last'] = {...} (at about line 390).
In ~/Whitelist, add ['автор'] = true to local limited_basic_arguments_t = {...}. Then add ['автор#'] = true to local numbered_arguments_t = {...} and to local limited_numbered_arguments_t = {...}
—Trappist the monk (talk) 23:16, 28 November 2023 (UTC)
Thanks a lot! :) Iniquity (talk) 01:42, 30 November 2023 (UTC)

Redundant listings in Category:CS1 maint: unflagged free DOI

Nice tracking category! However, this currently comes up with citations which do not need doi-access=free because they already have an auto-linking PMC identifier (example). That makes it harder to find citations which would actually benefit from being turned green. Nemo 10:57, 30 November 2023 (UTC)

|pmc= and |doi= point to different sources. |pmc= defaults to free-to-read; |doi= does not. |pmc='s free-to-read-ness does not apply to |doi=. Readers who would prefer to read the |doi= source are entitled to know if that source is free-to-read. All identifiers that are free-to-read should be marked with |<identifier>-access=free.
I don't know what you mean by That makes it harder to find citations which would actually benefit from being turned green.
—Trappist the monk (talk) 14:46, 30 November 2023 (UTC)
I mean that adding OA identifiers is most useful on citations which don't already have one. Once you have a PMC ID, the marginal utility of a doi-access=free parameter is significantly reduced. Nemo 15:06, 30 November 2023 (UTC)
cs1|2 does not support Open Access (OA) because open access implies that the source may be reused in some form or other. As far as cs1|2 is concerned, a source is free-to-read or it lies behind some sort of paywall or registration barrier.
The free-to-read icon attached to a PMC identifier conveys no useful information about the paywall/registration/free-to-read status of the source pointed to by |doi= or any other identifier parameter. In fact, the omission of a free-to-read icon for |doi= when |pmc= has a value implies that the source pointed to by |doi= lies behind a paywall or registration barrier.
—Trappist the monk (talk) 15:20, 30 November 2023 (UTC)
Alright, can we have a maintenance category for citations which don't have an OA identifier aka "free-to-read icon" then? Nemo 16:31, 30 November 2023 (UTC)
I guess I'm not sure how useful that would be. The cs1|2 module suite is used on more than 5.6 million articles so a list of all articles with cs1|2 templates that have identifiers but don't have a matching |<identifier>-access=free could number a million or more. It seems likely that many of those should never have a |<identifier>-access=free so those articles would live in the new category forever. How is that useful?
—Trappist the monk (talk) 20:59, 30 November 2023 (UTC)

Category:CS1: Julian–Gregorian uncertainty

Hello 🙂 I was wondering how you would go about removing an article from the hidden category above. There are over 100,000 pages tagged with this category, and at least to me, it's a little unclear how to fix this. I also see that this might be a temporary category, so, is there still a need for this, or can it be deleted? Kind of a two parted question, but I hope you understand. Cheers! Johnson524 15:39, 30 November 2023 (UTC)

You shouldn't bother; that category is a properties category not a maintenance or error category. It exists merely for the information it might contain. Here is some history:
Help talk:Citation Style 1/Archive 39 § metadata dates rfc
Help talk:Citation Style 1/Archive 41 § CS1: Julian–Gregorian uncertainty
Help talk:Citation Style 1/Archive 54 § Julian and Gregorian dates
Help talk:Citation Style 1/Archive 56 § Julian Gregorian uncertainty
Help talk:Citation Style 1/Archive 88 § Julian vs. Gregorian
Apparently no one cares about this anymore since those who do or did have never said anything here about it. That being the case, I'm going to remove the code that categorizes articles into Category:CS1: Julian–Gregorian uncertainty.
—Trappist the monk (talk) 18:40, 30 November 2023 (UTC)
Sounds good, thanks for checking up on this 👍 I'll be sure to take a look at those history links, cheers! Johnson524 18:46, 30 November 2023 (UTC)
Categorization gone from the sandboxen. You can test in mainspace (because property cats do not include pages in the Help namespace) with this:
{{cite book/new |title=Title |date=1 June 1815}}
—Trappist the monk (talk) 20:22, 30 November 2023 (UTC)
Happy to see this go, as I said in the last discussion it would be better handled by an inline template used in specific instances that editors believe to be at issue. -- LCU ActivelyDisinterested «@» °∆t° 15:17, 1 December 2023 (UTC)

Is there any way to incorporate interlanguage links, in e.g. |author parameters? ~~ AirshipJungleman29 (talk) 22:32, 2 December 2023 (UTC)

Yes:
|author=[[:<tag>:<article name>|<author name>]]
or:
|author-link=:<tag>:<article name> – required for |last= / |first= pairs; may be used for |authorn=
where:
<tag> is the target wiki's interwiki prefix (de for German, ar for Arabic, etc)
<article name> is the article name at the target wiki
<author name> is the author's name
Do not use {{Interlanguage link}}.
—Trappist the monk (talk) 23:35, 2 December 2023 (UTC)

The first of two questions about one particular paper that I intend to cite (via a CS1 citation template). The questions are, I think, otherwise independent of each other.

You'll find a page introducing the article at doi:10.1177/007542428902200202. To see the actual article, log-in (or payment) is required. However, I also found the article at this URL, which starts "https://citeseerx.ist.psu.edu" and for which log-in or payment is not required. Now, I am almost totally ignorant of Citeseerx, but as doi:10.1177/007542428902200202 works, I infer from Template:CiteSeerX's documentation that CiteSeerx: 10.1177/007542428902200202 should work too. It doesn't. Have I misunderstood something? -- Hoary (talk) 11:59, 3 December 2023 (UTC)

Looks right, so my guess would be that CiteSeerX has not indexed that document internally by DOI (or not by that DOI). If, as you say, you are using a CS1 citation template, there is no reason to use {{CiteSeerX}} in the first place; just do |url=https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=ca452b918dd0498837c9d127dae5b5db833e51ee and if you're concerned about its lifespan, make sure web.archive.org saved a copy (done). Similarly, normal DOI usage in CS1 would be |doi=10.1177/007542428902200202 not a {{DOI}} template.  — SMcCandlish ☏ ¢ 😼  12:29, 3 December 2023 (UTC)
Thank you, SMcCandlish. Yes, sorry, I sleepily forgot to say that I was using the CiteSeer and DOI templates only temporarily, intending to replace them with citeseer= and doi= within the Cite journal template. Yes, all of what you say makes good sense -- and thank you in particular for taking the trouble to get the Internet Archive to store the article. -- Hoary (talk) 21:56, 3 December 2023 (UTC)

Citing a pamphlet published or edited on behalf of

I'm citing a German pamphlet which is listed as published/edited on behalf of - Herausgegeben im Auftrage. The work was published on behalf of the organization „Reichsarbeitsgemeinschaft ‚Das kommende Deutschland'“. Johannes Täufer is listed as the author, and Astrologischer Verlag Wilhelm Becker is the publisher. What's the preferred way in {{cite book}} to record a "published on behalf of"? -Furicorn (talk) 08:03, 3 December 2023 (UTC)

If Astrologischer Verlag Wilhelm Becker is listed as the publisher, I would write |publisher=Wilhelm Becker.
—Trappist the monk (talk) 12:33, 3 December 2023 (UTC)
In cases of doubt where it's unclear if one party was just the printer and another was the publisher is a more "directorial" sense, I put both, since our citations are not articles about the works, and exist to help readers find the publication (both strings will help do that).  — SMcCandlish ☏ ¢ 😼  12:43, 3 December 2023 (UTC)
So would you say |publisher=Astrologischer Verlag Wilhelm Becker, on behalf of Reichsarbeitsgemeinschaft‚ "Das kommende Deutschland"? Thanks -Furicorn (talk) 19:43, 3 December 2023 (UTC)
Not sure about this case, since I've not researched the publication and the parties behind it. In cases where I can't tell anything for certain, I do something like |publisher=Astrologischer Verlag Wilhelm Becker / Reichsarbeitsgemeinschaft Das kommende Deutschland (the quotation marks being superflous), since the strings in question are still helpful in finding the source, but I needn't do any iffy OR on my own part to try to decide who "is" the "real" publisher. This also comes up in modern cases; e.g., Scientific Style and Format has specific individual author-editors of particular editions, and is (in recent editions) "published by" the Council of Science Editors in the editorial-direction sense and (again in recent editions) "published by" Chicago Univerisity Press in the printer sense. I can't predict what kind of "publisher" a particular reader cares more about (an editorial "publisher" has much more to do with reputability and bias, while a printing "publisher" is more important for how the book is indexed in bibliographic databases), so I would be inclined to included both in the citation, especially as it provides additional relevant search strings. But this probably comes up more for Victorian and earlier publications, in which it may be difficult to determine whether some non-notable company name at the bottom of the title page represents a printer hired to just do the job, or a publisher who had some editorial input, especially if juxtaposed with the name of an organization or other entity that clearly did have some control over it.  — SMcCandlish ☏ ¢ 😼  03:21, 4 December 2023 (UTC)
Thanks for the reply - I found the German National Library entry for the pamphlet (DNB-IDN 576618977), and based on that I figured out that the phrase meant that the author had written the work as a representative of the committee. So I added the committee name in the parameter |last=, similar to how the library had done it. -Furicorn (talk) 06:40, 4 December 2023 (UTC)
Should be in its own |author2= (equivalent to |last2= but clearer), not jammed into the same |last[1]= as the human author name, or it pollutes the metadata about what his name is.  — SMcCandlish ☏ ¢ 😼  15:49, 4 December 2023 (UTC)
Thanks! Very useful to know, I've gone ahead and done that.
-Furicorn (talk) 06:34, 5 December 2023 (UTC)

Two issue numbers, two years

A second question about a paper I intend to cite (via a CS1 citation template).

doi:10.1177/007542428902200202 describes an article as "First published October 1989" in "Volume 22, Issue 2" of the journal. Now look at the running header on evenly-numbered pages here at PSU. It reads: "JEngL 22.3 (October 1989 [1993])" [my emphases].

Now, if I were to read of a paper described as "1989 [1990]", I'd guess that it came out in a journal issue dated 1989 but in reality emerging only in 1990. But the journal wouldn't announce (in effect) "1989, nah, we're kidding, 1990". And I haven't heard of journal publication being delayed four years.

Informed comments? -- Hoary (talk) 11:59, 3 December 2023 (UTC)

This looks to me like it was first published in 22(3), Oct. 1989, but that the description of the article mistakenly has it as 22(2); and that it was later reprinted in 1993, or that 1993 is the date it was put online, or was revised in some way in 1993, or some other post-publication ocurrence. But it's hard to say without knowing more about the history of the periodical. It seems extremely unlikely to me that an issue published in 1989 would be 22(2) and an issue published in 1993 would be 22(3) rather than 26(X). If I were not able to get a clearer answer, I would cite it as |date=October 1989|volume=22|issue=3 to agree with the publication itself (as much as seems possible), rather than some third-party claim about its volume number; then follow the citation template, but still inside <ref>...</ref>, with something like 'Also dated "[1993]" suggesting a revision or republication.'  — SMcCandlish ☏ ¢ 😼  12:37, 3 December 2023 (UTC)
Good thinking, SMcCandlish. Shall do. -- Hoary (talk) 21:58, 3 December 2023 (UTC)
It seems that now we have heard of a publication being delayed four years: journal editor William A. Kretzschmar's 1995 note (TWL link) in volume 23 issue 1–2 (where the running header has "1990–1995") indicates that he was responsible for publishing the journal and events overtook him, leading to extreme delays for two volumes and handing over publication duties to Sage.
So the 1989 volume was published 1993, and the 1990 volume was published 1995. Not sure how to cite it accurately, but an interesting tale. Folly Mox (talk) 23:01, 3 December 2023 (UTC)
Blimey. I mean, great sleuthing, Folly Mox. -- Hoary (talk) 02:53, 4 December 2023 (UTC)
Well, lots and lots of things are written at an earlier time than they are published, and we use the date of publication not of authorship, so these could be cited as 1993 and 1995 respectively, or maybe with ranges like 1989–1993 and 1990–1995, though that might just be confusing. I guess it depends on what is shown in the actual publication. If it says "1990–1995", then having that in the citation might actually help locate the source, while if these dates are just researched background information they probably would not. A "we originally intended to publish this in 1989" date doesn't really mean anything in most cases.  — SMcCandlish ☏ ¢ 😼  02:58, 4 December 2023 (UTC)
Honestly I feel like this might be an appropriate use case for |orig-date=. But if I'm wrong, in terms of findability, the publisher (Sage, not the o'erburdened Dr Kretzschmar) has the "intended" publication date, so that might be the one to pick. Folly Mox (talk) 03:36, 4 December 2023 (UTC)
Seems like the journal sold themselves to SAGE, who has since done an atrocious job digitizing / putting up metadata for the archived papers. Publication date should be 1993, and optionally might have orig-date=Submitted 1989 or the like. –jacobolus (t) 17:48, 5 December 2023 (UTC)
Sounds reasonable.  — SMcCandlish ☏ ¢ 😼  07:57, 6 December 2023 (UTC)
But I think that the reader -- or, at the risk of sounding a bit snobbish, the kind of reader who'll want to read the kind of stuff that's distilled from academic journals -- will realize that "BITD" (before the interwebs) even the submission of an appreciatively received MS wouldn't bring fast publication. There's a difference between routine delays such as that on the one hand, and a hardly credible four-year delay on the other. To be more certain of how the paper is presented, I'd like to see the front cover and first few pages of the actual codex; but (lacking easy access to a university library) that would take more time than I'm eager to spend, so I shan't bother. And as for findability, it's hard to believe that anyone will do it by year (or even volume and number): far more likely they'll merely click on the DOI, or on an (apparently above-the-board) free copy, or on a Wayback copy of the latter. -- Hoary (talk) 06:29, 4 December 2023 (UTC)
Well, we can't depend on every reader having access to these links, per WP:REUSE, even the simplest re-use of someone printing out a copy before heading to a library. Otherwise we might as well have nothing in a citation at all but the URL when a URL is available. :-)  — SMcCandlish ☏ ¢ 😼  15:49, 4 December 2023 (UTC)

Extra text in |volume= and |issue=

We have Category:CS1 errors: extra text: volume and Category:CS1 errors: extra text: issue that list articles where a cs1|2 template has |volume= or |issue= with some sort of extraneous text that reflects the parameter name: |volume=Vol. XX or |issue=No. 13. There are at least a couple of thousand articles where the text that is extraneous to one parameter can be found in the other: |volume=No. 13 or |issue=Vol. XX.

This search (times out) finds ~1500 articles where the value assigned to |issue= begins with Vol (case insensitive)

This search (times out) finds ~700 articles where the value assigned to |volume= begins with Iss, Num, No, N°, № (case insensitive)

I propose to do one of two things:

  1. create separate tests for these conditions so that they can be categorized separately from the existing Category:CS1 errors: extra text: volume and Category:CS1 errors: extra text: issue
  2. modify the existing tests to include these conditions so that they will categorize into the existing categories

Opinions?

—Trappist the monk (talk) 20:37, 3 December 2023 (UTC)

@Trappist the monk: If you modify the existing tests to include these conditions so that they will categorize into the existing categories, then I'll update my existing bot tasks to fix these. GoingBatty (talk) 20:51, 3 December 2023 (UTC)
@Trappist the monk: Correction: I'll update my existing |volume= bot task, and submit an additional bot request to fix |issue=. GoingBatty (talk) 20:53, 3 December 2023 (UTC)
I've tweaked the sandbox to combine the currently separate lists of volume and issue patterns into a single list of patterns. I have also added tests for n° and №. When the test is run, the values assigned to |volume= and |issue= are checked against the combined patterns.
Cite magazine comparison
Wikitext {{cite magazine|magazine=Magazine|title=Title|volume=n° 32-33}}
Live "Title". Magazine. Vol. n° 32-33. {{cite magazine}}: |volume= has extra text (help)
Sandbox "Title". Magazine. Vol. n° 32-33. {{cite magazine}}: |volume= has extra text (help)
Cite magazine comparison
Wikitext {{cite magazine|magazine=Magazine|title=Title|volume=№2}}
Live "Title". Magazine. Vol. №2. {{cite magazine}}: |volume= has extra text (help)
Sandbox "Title". Magazine. Vol. №2. {{cite magazine}}: |volume= has extra text (help)
No change in categories.
—Trappist the monk (talk) 19:19, 6 December 2023 (UTC)

Impact of "Template:American transit ridership" edit

{{American transit ridership}} was updated 05:46, December 6, 2023. Apparently, this resulted in 300+ articles being added to "Category:CS1 errors: dates". Can a script be run to perform an "empty edit" on the articles in this category? I assume this will remove them from the category. User-duck (talk) 17:37, 6 December 2023 (UTC)

I have fixed the template. The Category:CS1 errors: dates (168) will empty on its own.
—Trappist the monk (talk) 17:43, 6 December 2023 (UTC)

Missing or incomplete template data

The following CS1 templates have missing or incomplete template data:

The template data goes into the documentation page, so any editor can add it, Rjjiii (talk) 19:57, 6 December 2023 (UTC)

Proposed script-author parameter

I'd like to re-raise a proposal that was previously supported at

specifically that the value of |script-author= be rendered in parentheses following the author name, and similarly for other people.

This is particularly important for Chinese and Japanese names, for which the romanized form is lossy. Many editors are adding the original names to other parameters, which messes up the metadata and (if |author= is used) the refname used by the {{harv}}/{{sfn}} family. The solution is to give them somewhere else to put this name so that it will be displayed.

I am not proposing the more elaborate forms suggested here. Kanguole 23:23, 25 November 2023 (UTC)

Outing myself as the editor who recently changed a related style guideline from recommending one wrong way to cite East Asian names (after the not-wrong way, ofc) to recommending a different wrong way.
I'd also be glad to see a |script-author= parameter join the other |script-parameter= team. Yes, the use case is different (don't need to worry about italics), but it would keep the metadata clean and allow shortened footnotes to function intuitively without use of |ref= (this applies to only one wrong way of citing East Asian authors).
Somewhere down the road, this could also help deal with the #Author roles problem discussed above, which current practice blocks. Lastly, |author-mask= is tedious, and fiddly when more than one author is attributed (since it suppresses commas, ampersands, and "and" between authors).
I recognise this is a whole can of cans (superior to a can of worms, which tbh should be stored fresh or dried), because it opens the door not only to |script-editor= but also potentially to |script-author16= and pals. Folly Mox (talk) 00:40, 26 November 2023 (UTC)
It's unclear to me whether this is a proposal for usage like 1) |script-author=zh to indicate the language, or 2) |script-author=李四 to provide the name in some other script. If no. 1, I can see this potentially adding utility, if COinS would support metadata to generate indicating the script used for the author name. If no. 2, then I don't see a reason for this when we have |author-mask=.  — SMcCandlish ☏ ¢ 😼  08:23, 26 November 2023 (UTC)
Any |script-parameter= requires both a language code and a value, separated by a colon, like |script-author=zh:顧愷之. The point (as I see it) is to be able to display the native names without touching the metadata or having to fiddle with |author-mask=, which requires duplicating information as well as sometimes including punctuation, which is difficult to remember. Folly Mox (talk) 09:23, 26 November 2023 (UTC)
Ah, I see. I like the idea of not redundantly repeating strings, but it comes at the cost of adding a complicated parameter (actually set of parameters) with two-part syntax, which seems very error-prone to me. Especially if |author-maskn= actually does work fine, just at the cost of some repeated name strings. 06:17, 27 November 2023 (UTC) — SMcCandlish ☏ ¢ 😼 
Not sure I understand why we need this. If the cited source provides both the native-script name and its transliteration then it seems to me that a concatenation of both can be included: |author=<native> (<transliteration>) or |author=<transliteration> (<native>). Is it common for sources to provide both? If not, then no need for |script-author=.
If the majority of ja or zh sources provide names in native and transliterated forms then perhaps there is a need for |script-authorn=. If that is the case, how are we to order the native and transliterated forms in the rendering? Native first? Transliterated first? Which of them contributes to the template's CITEREF id? Only ja and zh or do we also include ko?
—Trappist the monk (talk) 15:50, 26 November 2023 (UTC)
I would think we'd show Latin-script first, and emit that version in the metadata (both COinS and CITEREF), since this is en.wikipedia. And should probably be script-neutral, since it would be usable for Cyrillic languages, South Asian languages of various scripts, and so on.  — SMcCandlish ☏ ¢ 😼  06:17, 27 November 2023 (UTC)
"Need" is a strong word. It would be convenient for editors and not much more. I agree with SMcCandlish just above that transliterations would be displayed first, and the only version incorporated into the metadata.
While it would certainly be nice to be able to include people's native names in any script (to facilitate learning more about them or finding other publications in their native language), to my knowledge the only scripts that have one-way transliterations into Latin that cannot be reverse engineered are Chinese and Japanese. Some scripts that have various transliteration styles, such as Korean, will present the same name differently depending on the age of the source and possibly other factors.
|author-mask= works, and this idea would duplicate the (predominant?) use case that has grown up around it despite its original intent. It does seem cleaner and more intuitive to match the other |script-parameter= parameters for the "people" fields, and would flatten the learning curve a bit, be agnostic between punctuation and author attribution positioning, and reduce duplication of data, which makes it a more attractive best practice.
Side bonuses would be the ability to create a maintenance category for parentheticals in people fields, as well as the ability when |script-name=zh: or ja: or ko: is present, to set the default name presentation to last first instead of last, first.
I do understand that it would be non-trivial to implement, and isn't strictly necessary since the current system functions, albeit a bit hackily for this sort of information. Folly Mox (talk) 12:30, 27 November 2023 (UTC)
I'm a native Anglophone, and I sometimes have to look at the original Hebrew before I can parse a transliterated word. I suspect that transliterations of other Semitic languages are also problematicval -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:37, 27 November 2023 (UTC)
On the question of sources, it's not especially common to provide both native and transliterated names in the publication by the author, but it does happen. This is more common in books than journal papers, and mostly confined to the humanities while absent in the sciences. In bibliographies (which is basically what we're doing), the practice seems almost universal in the humanities.
The major use case of knowing a person's real name, for me, is to be able to identify them in native language publications. This lets me locate the original source, find out if there's more by them on a subject, check their reputation and affiliation, and see if there's an interwiki article about them if en.wp lacks one.
I don't recall ever seeing an English Wikipedia article where Chinese authors are credited solely by their native names, and the practice is already widespread of including both versions where |author-link= has no target.
One final point is that this goes both directions, for example Sarah Allan is credited under the transliterated name 艾蘭 when publishing in Chinese language publications, Edward Shaughnessy writes under the name 夏含夷, etc. I'm not aware of any cases of English Wikipedia citing zh / ja language sources by authors who write predominantly in English and other Latin script languages, but we would want to have both versions of the name for these sources as well so they could be located for verification. Folly Mox (talk) 13:10, 27 November 2023 (UTC)
This crude search (times out) suggests that editors do write |authorn= parameters using only non-Latin characters. There are lots of results where |authorn= is empty or has languages other than CJK, but still there are plenty of CJK-only author names.
This crude search (times out) attempts to find |authorn=<romanized> (<native>).
This crude search (times out) attempts to find |authorn=<native> (<romanized>).
The latter two searches suggest that en.wiki editors do not commonly include both native and romanized versions of author names.
I asked Is it common for sources to provide both? because somewhere around here there is some instruction that editors should not engage in translation of quoted text. I view romanization of non-English names as a form of translation. In much the same way that |trans-title= should not be used if the source itself does not provide an English translation, so too, if the source itself does not provide a romanization of a native name, en.wiki editors should not attempt to romanize those native names.
—Trappist the monk (talk) 16:00, 27 November 2023 (UTC)
Huh I've always followed the guidance at WP:RSUEQ: If you quote a non-English reliable source (whether in the main text or in a footnote), a translation into English should accompany the quote. Translations published by reliable sources are preferred over translations by Wikipedians, but translations by Wikipedians are preferred over machine translations.
I consider citing a source as being in the same sphere as quotation, and almost always translate titles if I'm able. Transliteration of Chinese names is usually easy, to the point where most Chinese names could be transliterated by algorithm with very few errors.
As an aside, on articles where only native names are used in the bibliography, are shortened footnotes of the form {{sfnp|劉|2010}}? Seems like it might be offputting for our target audience. Folly Mox (talk) 17:15, 27 November 2023 (UTC)
But RSUEQ is about inline and block quotations in the article body (or in the |quote= parameter of a citation), which are meant to be read and understood by our readers as prose. But our citations of source titles and authors are not article content in this sort of sense; the only reason we have them is for identifying and finding the sources to verify the content, so there is no need to make up or machine-generate a source title or author title transliteration or translation, since it won't match the actual title/author of the source as published and thus won't help find it, and may even mislead the reader into picking the wrong source that happens to have the same name in English. It is noteworthy that the "Citing" section, right above the "Quoting" section that is the target of the WP:RSUEQ shortcut, does not advise providing translations or transliterations. It is not an accident. As I noted earlier (below) someone might argue that there is still some kind of reader utility in providing such translations or transliterations anyway, but there are counters to this argument.  — SMcCandlish ☏ ¢ 😼  23:16, 28 November 2023 (UTC)
Wikipedians adding their own personal or tool-generated transliterations and translations for source titles and transliterations for authors probably is not a good idea; it leans toward WP:OR (though I guess it's not technicaly part of the "article content" in the strict sense), is potentially error-prone (or bias-prone, e.g. favoring an old "traditional" transliteration style that is no longer the one typically used), and doesn't do anything to help anyone find the source, which is what the citation is for (it's not to satisfy someone's idle curiosity about what 基 might look like transliterated into Latin text). On the other side of such an argument, there are AI-fuelled translators and transliterators and if they produce pretty consistent results, then a transliteration of an author name and a translation of an article title might actually be pretty accurate. Then a counterpoint to that is it might be downright unhelpful: e.g. the real source is "החיים שלי עם חתולים", which transliterates as "Hachaim shley am alett" which is basically usless, and translates into English as "My life with cats", but Googling around for that English pseudo-title will turn up all sorts of results [4], probably none of which will be the source cited. And then an argument in the other direction might be that at least the reader would be able to see something about what the source is about, from its title translation, and even editors might be better able to detect when a bogus source has been added, e.g. if the title translates to "Triumphs of the Soviet Space Program" but the article is about the Kievan Rus', there is probably an issue. So, I'm not entirely sure, but still lean toward "don't add your own transliteration or translation of citation details".  — SMcCandlish ☏ ¢ 😼  00:00, 28 November 2023 (UTC)
I mean, as far as I'm aware, MOS:CHINA has always said If a work is in an East Asian language, the original title should be romanized.... Names of publishing companies or presses are transliterated but not translated.... Sure, if someone only provides a translation of the title, you'll never find it to verify, but the guidance says to transliterate, which is hardly biased or error-prone. I like to provide translations of title in addition to the originals and usually transliterations, because it gives people an idea what the source is about (other than "an editor claims it verifies some content").
Seems a little weird that people trust editors to read foreign language sources and summarise their contents, but not to provide a direct translation of the name of a published source (or even transliterate a name? which is like, how do you think we refer to things in article prose when they don't have an article here?).
When writing about foreign language topics, editors translate all the time. It's part of the work. Something like translating the name of a source is the same basic level of competency as routine calculation. It's not OR to be able to read a second language. Folly Mox (talk) 00:29, 28 November 2023 (UTC)
Oops I shoulda scrolled up from my previous link. WP:TRANSCRIPTION says Faithfully translating sourced material into English, or transcribing spoken words from audio or video sources, is not considered original research. Folly Mox (talk) 00:33, 28 November 2023 (UTC)
I'm skeptical that the MOS:CHINA material on this actually represents a broad consensus. I strongly suspect that if an RfC were put up at WP:VPPOL asking "In citations, should source titles and author names in non-Latin script be transliterated by editors into the Latin alphabet (or translated into English) when the publication itself only provides the name(s) in the original non-Latin script and non-English language?" the answer would be "No (and no)", because it does not help the reader find the source, which is what citations are for. Aside from the uncommon |quote= parameter, our citations are not "content" in the usual sense, but serve a specific purpose. An argument can be made that the publication company being transliterated does help evaluate the source, since we (or someone else) may have information about the publisher that could help in evaluating reputability, especially when it comes to things like distingishing between a university or general book publisher versus a govermental organ or a game company that published the game our article is about, for example. I honestly don't really feel all that strongly about it, but I suspect that other editors do, and this is actually worth putting to a broad RfC audience somewhere like VPPOL.  — SMcCandlish ☏ ¢ 😼  23:16, 28 November 2023 (UTC)
I suspect the guidance is misaligned as well, but not in the same way. I suspect people would prefer, for titles, native and translations, with no transliterations. Transliterations of titles is common in academic publishing for some reason (possibly grandfathered in due to inability to print 漢字 until like the nineties), but adds nothing for the reader, except when both: accompanied by the native title, and the reader is a student of the language and doesn't know how to pronounce things.
I know for me personally, when I see a citation in a script I can't read, it's deeply comforting to have the transliteration of the names and translation of the title. This doesn't assist in verification, but it gives me some idea, in my brain, who is being cited and what the work is about, in a broad sense. Folly Mox (talk) 19:06, 29 November 2023 (UTC)
But that's a personal whim you can satisfy in seconds of your own time using Google Translate. It doesn't "translate", if I may pun, into a need for Wikipedia editors do this work for you, in untold thousands of citations. I encounter Chinese, Russian, etc., citations all the time and am not perturbed by them. If I want to know what the title "宇多田ヒカル、11年ぶりシングルCD発売決定 Skrillexと『キングダムハーツIII』OP制作" translates to, I can take a few seconds to paste it into Google Translate.  — SMcCandlish ☏ ¢ 😼  08:04, 1 December 2023 (UTC)
It's unjustified to require that people use machine translation/transliteration for this: those are not trivial tools, and we should try to impose Google Inc. (et al.) on people as little as possible. They are also not perfect, especially for languages that use Chinese characters. Remsense留 18:27, 1 December 2023 (UTC)
Wikipedians should absolutely add both transliterations and translations of foreign text. This is an English encyclopedia and we don't expect readers to be able to handle random snippets of Urdu, Ancient Greek, Nahuatl, and Swahili interspersed with the English. –jacobolus (t) 17:30, 29 November 2023 (UTC)
Examples from Lexell's theorem:
Schubert, Friedrich Theodor (1789) [written 1786], "Problematis cuiusdam sphaerici solutio" [The solution of a certain spherical problem], Nova Acta Academiae Scientiarum Imperialis Petropolitanae (in Latin), 4: 89–94
Shvartsman, Osip Vladimirovich (2007), "Kommentariy k stat'ye P. V. Bibikova i I. V. Tkachenko 'O trisektsii i bisektsii treugol'nika na ploskosti Lobachevskogo'" Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» [Comment on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle in the Lobachevsky plane'] (PDF), Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130
Steiner, Jakob (1827), "Verwandlung und Theilung sphärischer Figuren durch Construction" [Transformation and Division of Spherical Figures by Construction], Journal für die reine und angewandte Mathematik (in German), 2 (1): 45–63, doi:10.1515/crll.1827.2.45, EuDML 183090
Chasles, Michel (1837), Aperçu historique sur l'origine et le développment des méthodes en géométrie [Historical overview of the origin and development of methods in geometry] (in French), Brussels: Hayez, Ch. 5, §§ 42–45, "Géométrie de la sphère" [Spherical geometry], pp. 235–240
Of course where available it's nice to use someone else's translation, e.g.:
Lexell, Anders Johan (1784) [written c. 1777], "Solutio problematis geometrici ex doctrina sphaericorum", Acta Academiae Scientarum Imperialis Petropolitinae (in Latin), 5: 1781 (1): 112–126, figures tab. 4, translated as "Solution of a geometrical problem from the theory of the sphere" (PDF), 17centurymaths.com, translated by Stén, Johan Carl-Erik, 2009
–jacobolus (t) 17:42, 29 November 2023 (UTC)
Well, just expressing "absolutely should" without providing a rationale other than a tautological observation of what site this is, and providing some examples of you writing citations the way you like to write citations, isn't very convincing. :-) I'm dead certain that if this question is put to an RfC, as I suggested above, that the input will be broad in its responses. I'm skeptical there would be much support for doing this, except in cases where off-site sources provide them and they help actually find the citation. Transliterations are generally meaningless to much of anyone (except when commonly used in RS for the same referent), and translations are unlikely to help find a verify the source (except when it's also been published in an English version, in which case we should be citing that instead).  — SMcCandlish ☏ ¢ 😼  14:28, 30 November 2023 (UTC)
The rationale is that readers of English text are not expected to know what "verwandlung und theilung", "cuiusdam", "aperçu", or "трисекции и бисекции треугольника на плоскости Лобачевского" mean (and it's even harder to puzzle out if the text is written in Marathi or Cantonese). These labels are often treated by English readers are opaque or even unrecognizable symbols without internal meaning. If not only the title but also the author name, publication name, etc. are in a non-Latin script, then the whole thing just becomes a blob of meaningless scribbles.
This makes it impossible for readers to evaluate what the source is about, what it has to do with the content of the article, whether/why it is important, whether they have seen it mentioned before, whether it's worth trying to find a copy of to examine (or e.g. get a machine translation of), and so on.
I don't really care about a transliterated title if we have a script title and a translation, but let's compare with/without a transliterated author name/journal and translated title:
Шварцман, Осип Владимирович (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского», Математическое Просвещение, Третья серия (in Russian), 11: 127–130
Shvartsman, Osip Vladimirovich (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» [Comment on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle in the Lobachevsky plane'], Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130
A recognizable author name and a legible title are the two single most important elements to include in a citation. The rest can be convenient but is mostly dispensable (motivated readers can find it if they need). –jacobolus (t) 15:24, 30 November 2023 (UTC)
But there is no point in "recognizing" that Шварцман transliterates to Shvartsman if this does not help the reader find the source. If the source is only available in Russian, then the strings to search for to find it are literally "Шварцман" and "Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского»" ([5], very first search hit, link toward bottom of short resulting page, then click the PDF button on the next page; took just a few seconds). If the source does exist in English then we should be citing that instead. Meanwhile, the translated strings "Shvartsman" and "Commentary on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle on the Lobachevsky plane'" don't help find the source at all (wild goose chase). Our citations do not exist to satisfy curiosity about how Cyrillic strings transliterate or translate into Latin script or English language, only to help the reader find the citation and verify the content. Any reader that cannot read the Cyrillic in the citation cannot read the Cyrillic in the source book/article, either, so cannot verify the citation and has to rely on someone else to do that work, so is not harmed by a transliteration not being provided. Meanwhile, the reader who is competent to read that material does not need that extra stuff. Any reader who is just really curious what a particular cited work's title translates to can just copy-paste it into Google Translate or an equivalent tool. It's not really the job of our templates and our editors to do that make-work for them, since it doesn't help with verifying our content. I used to think about this the way you do, and went to pains at articles like Utada Hikaru to provide translations of work titles, and it was a lot of work, but in the end it simply doesn't help anyone verify the content, and it just adds a lot of code bloat and a lot of visual cite bloat for the reader, without actually providing utility to them.  — SMcCandlish ☏ ¢ 😼  07:44, 1 December 2023 (UTC)
Transliterations are often provided and utilized haphazardly in journals and the like, providing a transliteration is rather likely to increase one's search results on a given individual. — Remsense留 07:54, 1 December 2023 (UTC)
Perhaps for names of people, and when dealing with languages/scripts that have a consistent transliteration system. But several do not, and translations of titles aren't going to match someone else's translation, except in the simplest cases (which will also, in being so simple, have lots of false-positives in English anwyay, so still not a help in finding the source). I can maybe concede that transliteration of author/editor names could be of some use, for the same reason as with publisher names: doing some background research of one's own to get a sense of reputability. PS: I added some example search stuff, and so on, to my previous post just above this but edit conflicted with you.  — SMcCandlish ☏ ¢ 😼  08:10, 1 December 2023 (UTC)
only to help the reader find the citation and verify the content – to first approximation, precisely zero readers care about "verifying the content". What readers care about is making sense of the subject. For readers who speak English and have no experience with Russian or related languages, the Cyrillic alphabet is entirely nonsensical, and barfing blobs of Cyrillic at readers is unhelpful and snobbish. Anyone can click the hyperlink to find the paper in Russian (and if they don't read Russian but want to make sense of it, as I did, they can OCR the image-based PDF and then machine translate the resulting text so they can understand the proof contained in the paper and cited by the article). But as for your point about web searches, Osip Shvartsman returns a wide variety of relevant results in English. Осип Шварцман does not. Edit to add: The #1 result in your "wild goose chase" search is a highly relevant paper in English (translated from Russian) which cites the paper in question ("O. V. Shvartsman. Comment on the article by p. v. bibikov and i. v. tkachenko. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):127–130, 2007.") and the paper it was responding to ("P. V. Bibikov and I. V. Tkachenko. On trisection and bisection of a triangle in the hyperbolic plane. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):113–126, 2007."), probably the single most relevant possible English language search result. Good job Google! –jacobolus (t) 08:19, 1 December 2023 (UTC)
That view is completely inconsistent with our verifiability policy, which is crystal clear that our material is sourced with citations so that readers can verify it. The average reader is not going to do this, and they "make sense of the subject" by reading the article content that interests them, not by looking at citations. Most of our readers never look at any of the citations. The ones who do are mostly students, journalists, people experienced in the topic, and those intensely interested in the topic and being certain about the facts, and these are the people our citations are for. They are the people who go find the cited source (at least when easily available) and see what it says. But ultimately we all know by know that that primary (by orders of magnitude) actual users of our source are other editors doing V and OR checking work to make sure our article are not full of nonsense. All of these classes of users, however, are going to be using the citations the same way: to find the source and see that it backs up the content we cite to it. "Anyone can click the hyperlink to find the paper in Russian", sure when it's an online source that is not paywalled, but many source are not, and we provided all the source info we have that is helpful in finding the source (not in learning other factoids about the source that are not necessary for finding it) because we cannot guarantee that an online one will be online indefinitely, and we also have WP:RESUSE to consider, from programmatic repurposing of WP content to just users print out articles on paper, where links don't work. WP:NOT#DATABASE, including a bibliographic one. There are all sorts of details about a source that we could include but do not, such as how many total pages it has, whether is a paperback or a hardback, who illustated the cover, etc., etc., etc. We don't include it because it doesn't help find the source."a highly relevant paper in English (translated from Russian) which cites the paper in question" is irrelevant. [{WP:SAYWHEREYOUGOTIT]]. We are not citing some other paper that mentions the paper we are citing, we are citing the paper we are citing. That is the purpose the citation serves, to find that source. That doing something else might be entirely accidentally "interesting" for someone in some way is a moot point. We could make all our citations vaguely interesting and useful, in an off-topic sense for citations, in a myriad of ways (e.g. including images of book covers, linking directly to shopping sites to buy them, providing word-count and reading-level analyses of them, connecting author names to databases instead of WP articles, linking to book reviews as adjunct information, and so on), but we do not because it's not the point of the citation or of Wikipedia.  — SMcCandlish ☏ ¢ 😼  11:11, 1 December 2023 (UTC)
This discussion has already digressed pretty far from "should we have a |script-author= parameter to match the others instead of relying on |author-mask= hacks?", but I agree with jacobolus and Remsense here, while noting that the previous time this talkpage hosted a digression into the philosophical argument of "what citations are for" versus "how citations are used", (in the "Do we need |access-date ?" thread still live above), several of the protagonists came down on opposite sides to where we find ourselves this time round. Folly Mox (talk) 11:35, 1 December 2023 (UTC)
FWIW, I think a script-author parameter sounds like a good idea. This kind of question should be left up to author discretion, and letting template users put the author name in two forms is a pretty obvious help with that. –jacobolus (t) 15:15, 1 December 2023 (UTC)
The fact that debates on this page come to contradictory-leaning results is not a surprise due to the small number of participants here. This is why I routinely suggest holding WP:VPPRO or WP:VPPOL RfCs on matters that are apt to ultimately affect many thousands of articles across random categories. Citation templates doing what they do for particular reasons with a strong WP:CONLEVEL behind them is much easier to support than "it's working this way right now because five people one day thought it seemed like a good idea and weren't inclined to brook any opposition".  — SMcCandlish ☏ ¢ 😼  01:57, 2 December 2023 (UTC)
I am in favor of an RFC if it achieves the best-developed results, but since I was not privy to previous aforementioned discussions, I wish it would have been explicitly proposed earlier. Remsense留 02:24, 2 December 2023 (UTC)
The example of transliterating החיים שלי עם חתולים as Hachaim shley am alett is useless not because it is a transliteration, but because it is not a correct transliteration. "Hachaim Sheli Im Chatulim" would be more helpful, although there are some dialect differences, especially for the consonants ח (Chet) and ע (Ayin). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 30 November 2023 (UTC)
Re: "an English Wikipedia article where Chinese authors are credited solely by their native names" – I've run into this many times for both Chinese and Japanese, and it's almost always a non-English news/web source. So, maybe not something we encounter in journals, but for looser types of sourcing, it's pretty common (but also applies to South Asian languages, Cyrillic ones, Hebrew, Korean, and so on).  — SMcCandlish ☏ ¢ 😼  23:38, 27 November 2023 (UTC)
Oh right, of course people cite only native names when they're using a referencing script to handle all the work for them. I'm not sure why I didn't think of that. Folly Mox (talk) 01:03, 28 November 2023 (UTC)
I would like to endorse the proposal for the reasons Kanguole and Folly have already stated: as someone who spends a lot of time wrangling citations involving the Sinosphere, a new feature like this, consistent with those already existing in the CS1 template is very near the top of my wiki-wishlist. Remsense留 01:27, 30 November 2023 (UTC)
I strongly endorse the proposal for the numerous reasons given above. That |script-title= has existed for years shows prima facie that the feature would be useful, as the author is at least as important as the title. I arrived here when I tried to use {{cite book}} to add a source where authors provided their names in both the source Chinese and Romanized. The Chinese is needed to match their names to catalog entries where machine-generated Romanizations are different from the ones they give in this source, while the Romanizations in this book are needed to match this source with other sources with no Chinese to establish that the authors are the same. —  AjaxSmack  17:11, 7 December 2023 (UTC)

cite book abruptly stopped working

Hi, first, thanks for all the work you put into making this! It has saved me a lot of time.

Early this evening, however, my requests to {{cite book}} in order to fill in additional information on the basis of the isbn field started generating a little Wikipedia box with the message "Error: Citations request failed" and the "option" to click OK. I am especially puzzled because it was working fine just a few hours earlier with an identical command.

I've tried it in other userspaces on Firefox and then on Safari and got the same thing. You can see my efforts here.[6]

Cheers, Patrick J. Welsh (talk) 05:10, 7 December 2023 (UTC)

It's working again! Many thanks if anyone did anything to resolve this! Otherwise please disregard the above.
Cheers, Patrick J. Welsh (talk) 06:37, 7 December 2023 (UTC)
User:PatrickJWelsh, the CS1|2 templates themselves don't have the functionality to look up additional information based on a stable identifier like an ISBN. I'm not sure which tool you were using to do this, but I know that some ISBN lookup tools have been using Worldcat as their lookup database, which is being changed. Separately, the backend framework for a number of older tools is being deprecated soon, so the blink in functionality you saw a few hours ago could have been someone migrating a tool to the new backend, or an accessibility problem with an external database, but has nothing to do with citation templates. Just fyi. Folly Mox (talk) 12:43, 7 December 2023 (UTC)

Need some sort of "id"/"ref" or similar parameter for some citation templates

In particular for Template:Cite press release, there is often an official id or reference number associated with pressers that would be great to be able to preserve and document in the {{cite ...}} reference, not in the least because it would aid the ability to search for alternative or archived urls if the source is dead. I can also see the need for other citation formats.

For an example, URL https://press.un.org/en/2022/ga12417.doc.htm is a UN press release with the ID GA/12417 that can be googled to find news articles or resolutions referencing the press release in question. Mahmoud (talk) 21:00, 9 December 2023 (UTC)

You can use |id= for this purpose. -- LCU ActivelyDisinterested «@» °∆t° 21:03, 9 December 2023 (UTC)
See Template:Cite press release#Identifiers for more information. – Jonesey95 (talk) 23:44, 9 December 2023 (UTC)

module suite update 25–26 November 2023

I propose to update cs1|2 module suite over the weekend 25–26 November 2023. Here are the changes:

Module:Citation/CS1

Module:Citation/CS1/Configuration

  • Swiss German fix; discussion
  • make extra text in volume non-hidden as it is kept clear these days
  • upgrade numeric names maintenance message to error
  • add Greek character sort keys for error/maint messages in non-article namespaces
  • add maint cat for unflagged free-to-read dois; discussion
  • update emoji_t to unicode v15.1; discussion
  • remove no-longer-supported |chapterurl=;
  • support single letter 2nd level domains for media TLD; discussion
  • fix for phab:T117845
  • deprecate |authors=
  • unhide missing-periodical error messages; discussion

Module:Citation/CS1/Whitelist

  • deprecate |authors=;

Module:Citation/CS1/Date validation

  • |archive-date= / timestamp check to use internal reformatter for i18n; emit suggested date; discussion

Module:Citation/CS1/Identifiers

  • add maint cat for unflagged free-to-read dois;

—Trappist the monk (talk) 23:34, 18 November 2023 (UTC) +last minute bug fix 15:27, 25 November 2023 (UTC)

Right now the numeric maint is emitting when the numeric error emits. It would be good to emit only the error in such cases. Izno (talk) 18:57, 25 November 2023 (UTC)
True, but when that happens it doesn't happen for the same parameter. For example, this emits two messages, the error message for |author=1234 and then maint message for |author2=4D2
{{cite book |title=Title |author=1234 |author2=4D2}}
1234; 4D2. Title. {{cite book}}: |author= has numeric name (help)CS1 maint: numeric names: authors list (link)
So not really redundant messaging.
—Trappist the monk (talk) 19:46, 25 November 2023 (UTC)
The maintenance cats also need to be updated for the new use, which is some numbers in the name, and recommended disposition (or not). Izno (talk) 18:58, 25 November 2023 (UTC)
Did that while you were writing you message.
—Trappist the monk (talk) 19:46, 25 November 2023 (UTC)
@Trappist the monk: Hi, I'm not sure if this issue was caused by this change or if I missed an earlier change that caused this, but 'CS1 maint: numeric names: authors list' is now being flagged for {{Cite tweet}} when there is a number in the |user= parameter even if there is no number in the |author=, |first=, or |last= parameters. I noticed this at Star Trek: Picard (season 1) which has a Twitter reference called "Culpepper3Split" where it is valid for the |user= parameter to have a number in it. I tested removing the number and it cleared the warning. - adamstom97 (talk) 01:13, 28 November 2023 (UTC)
That maintenance message is new with this update. {{cite tweet}} concatenates |last=Culpepper, |first=Hanelle, and |userHillview798= into |author=Culpepper, Hanelle [@Hillview798] which it hands off to {{cite web}} for rendering. This is not a {{cite web}} or Module:Citation/CS1 problem but is a problem of Module:Cite tweet – |user= value, the brackets, and the @ symbol do not belong in |author= as given to {{cite web}}.
You should raise this issue at Template talk:Cite tweet. See Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023 which describes a different but related problem. A solution proposed for that would have addressed both problems but was not adopted. I don't know why.
—Trappist the monk (talk) 02:07, 28 November 2023 (UTC)
Cool, thanks for the explanation. - adamstom97 (talk) 02:16, 28 November 2023 (UTC)
Which solution are you pointing to, the author-mask or the substitution? I'm having a hard time making sense of this :\ SWinxy (talk) 05:57, 28 November 2023 (UTC)
I don't know what you mean by the substitution. That term does not appear in the discussion I linked: Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023.
—Trappist the monk (talk) 15:09, 28 November 2023 (UTC)
I mean gsubbing the author field, which is what you seem to have proposed. SWinxy (talk) 16:42, 28 November 2023 (UTC)
Do you mean lines 39–41? Please be explicit; don't make me pull out your teeth one by one...
—Trappist the monk (talk) 16:53, 28 November 2023 (UTC)
Yes. Sorry, I'm trying to wrap my head around what was proposed to fix those problems. SWinxy (talk) 21:28, 29 November 2023 (UTC)

In addition to removing errors for {{Cite tweet}} when there is a number in the |user= parameter, we need to allow all CS1 templates to have digits in the author parameter. Template:Citation Style documentation says "author: this parameter is used to hold the name of an organizational author (e.g. a committee) ..." That would include, for example, The Jackson 5, OS/2 Development Team, Windows 95 Development Team, and thousands of other possible organizational authors that have digits. —Anomalocaris (talk) 11:48, 13 December 2023 (UTC)

Of course. The primary purpose of the maintenance category/messaging is to catch the junk that citoid-supported tools dump into the various name parameters, |last2=May 02, and the like (there are lots of name parameters that contain date fragments). Valid names-with-digits like those you list as examples are relatively uncommon but can be excluded from the maintenance category. Compare these:
{{cite book |title=Title |author=OS/2 Development Team}}
OS/2 Development Team. Title.{{cite book}}: CS1 maint: numeric names: authors list (link)
{{cite book |title=Title |author=((OS/2 Development Team))}}
OS/2 Development Team. Title.
—Trappist the monk (talk) 14:13, 13 December 2023 (UTC)
Anomalocaris, this syntax is documented at Help: Citation Style 1 § Accept-this-as-written markup, although it's admittedly not particularly intuitive to find the solution when you're experiencing this problem. Folly Mox (talk) 14:19, 13 December 2023 (UTC)
Trappist the monk, Folly Mox: Thank you, I had forgotten about that workaround. —Anomalocaris (talk) 18:57, 13 December 2023 (UTC)

Fixing Citoid created references for Youtube

Tracked in Phabricator
Task T278281

Hi all

Youtube is the second most popular website in the world, with a huge number of reliable news sources using it as a platform for sharing video. Unfortunately Citoid doesn't work properly for creating refs for Youtube currently. This leads to poor quality labelling of references being made, and while there are some templates to specifically cite video content, they aren't user friendly at all. I started a Phabricator ticket in 2021 to try and address this issue, however its not been worked on. Can I request anyone interested in this:

  • Subscribe to the Phabricator task so its made clear this is an issue many people would like to be fixed.
  • Try citing Youtube videos in articles and give feedback in the Phab task if you notice anything I haven't mentioned.

Also just to say I've seen a couple of people say "Youtube is an unreliable source and shouldn't be used", I think this is a missunderstanding of what the platform is, its the channels that should be assessed for reliability rather than the publishing platform as a whole. E.g the BBC News channel is reliable (its listed under Perennialy reliable sources on en.wiki), where as My Toy Reviews or DailyWire or whatever are obviously not reliable.

Thanks very much

John Cummings (talk) 08:56, 8 December 2023 (UTC)

While we're on this topic, people really, really, really need to stop doing |publisher=YouTube. Unless you're citing something like YouTube's own terms-of-use policy (something actually published by YouTube), it's |via=YouTube, and the |publisher= (if not omitted as often completely redundant with the name of the channel, which belongs in |work=, with the specific video title in |title=) must be the name of the entity that editorially controls and originated the content. YouTube is just a conduit/platform/carrier. Doing |publisher=YouTube is like saying that your mobile service provider owns and originated and has editorial control over your phone conversations with your sister.  — SMcCandlish ☏ ¢ 😼  11:49, 8 December 2023 (UTC)
Hi SMcCandlish can you please include this as a request in the phabricator ticket so it gets integrated into the work for whoever might work on it. Thanks, John Cummings (talk) 13:35, 8 December 2023 (UTC)
Done.  — SMcCandlish ☏ ¢ 😼  03:33, 9 December 2023 (UTC)
SMcCandlish, thanks :) John Cummings (talk) 08:21, 9 December 2023 (UTC)
People who use Citoid and people who manually set template parameter values have near zero overlap. Folly Mox (talk) 13:40, 8 December 2023 (UTC)
I do both all the time. It's far quicker to create cites using autofill, but not always possible (or desirable as it sometimes autofills nonsense). -- LCU ActivelyDisinterested «@» °∆t° 15:10, 8 December 2023 (UTC)
Yes. People who use tools like this should be checking and where necessary manually cleaning up with generated citations before clicking "Publish changes".  — SMcCandlish ☏ ¢ 😼  03:33, 9 December 2023 (UTC)
I've had to rebuild the referencing of many articles that ReFill or other tools have nuked. It would be useful to have error messages flash up when editors hit publish. -- LCU ActivelyDisinterested «@» °∆t° 14:55, 9 December 2023 (UTC)
I feel your pain.  — SMcCandlish ☏ ¢ 😼  02:52, 11 December 2023 (UTC)
Same. The whole idea that an algorithm can reliably produce accurate citations based solely on html metadata is uh folly. The full page has to be parsed, and sometimes even then it's not possible because some values load in through javascript. Evidently Zotero gets it right more often because their translators can follow after javascript loads in the client, but anything that runs on Citoid should have a minimum permissions group and a rate limit. Folly Mox (talk) 05:04, 11 December 2023 (UTC)
A rate limit sounds a good idea, many of the issue Wikipedia seems to face is editors running automated processes without any real oversight. By the time they get stopped they can in short order create a huge mess for other editors to clear up. -- LCU ActivelyDisinterested «@» °∆t° 15:31, 11 December 2023 (UTC)
{{cite web|website=Newspapers.com|title=New York Times - 1|archive-url=[...] Rjjiii (talk) 05:07, 11 December 2023 (UTC)
CS1 documentation is unclear and poor. I have detailed such issues here before, but I've only ever seen variations on the same response -- that if editors misuse parameters it's their own fault.
(If people are regularly misusing the parameters of your function, it's because your function documentation and/or semantics are inadequate.) SamuelRiv (talk) 04:16, 9 December 2023 (UTC)
SamuelRiv if you have any suggestions for best practice when citing videos hosted on Youtube, please dd them to the phab task :) John Cummings (talk) 08:21, 9 December 2023 (UTC)
Also, If you believe that the cs1|2 documentation needs to be improved, please improve it. The documentation is not protected so anyone may improve the documentation.
—Trappist the monk (talk) 12:56, 9 December 2023 (UTC)
This is a classic problem, people think the help documentation is poor but no-one wants to write help documentation. -- LCU ActivelyDisinterested «@» °∆t° 15:33, 11 December 2023 (UTC)
Hmph. I write more documentation that just about anyone on-site, but pretty much every time I touch those pages of documentation I get insta-reverted by one or two, um, "over-controllers" of their content. (I quite literally have a much higher success rate editing core policy pages.) It's basically too discouraging to much bother with. I only try it every few years or so, and it hasn't gotten any better/easier to get sensible changes to stick (other than fixing typos or code errors).  — SMcCandlish ☏ ¢ 😼  22:07, 12 December 2023 (UTC)

email not flagged

Hello, in this version of Miss Brazil CNB 2022 which has |last2=email, "CS1 errors: generic name" is not reported. Keith D (talk) 01:53, 13 December 2023 (UTC)

Local dates

Hello, I seem to have specified everything in the configuration, but it still does not want to read dates correctly in the local language: ru:Участник:Iniquity/test date - displays an error with the date. What could it be? Iniquity (talk) 18:32, 14 December 2023 (UTC)

I think that you need to set local_date_names_from_mediawiki = false; (line 615 in ru:Модуль:Citation/CS1/Configuration). When that is set true, the module overwrites your manual translations so the month-names that you used in your example (2 ноября – 21 декабря 1968) no longer exist. I think that I confirmed that with this in the debug console: 
=mw.dumpObject (p.date_names['local']['long'])
table#1 {
    ["август"] = 8,
    ["апрель"] = 4,
    ["декабрь"] = 12,
    ["июль"] = 7,
    ["июнь"] = 6,
    ["май"] = 5,
    ["март"] = 3,
    ["ноябрь"] = 11,
    ["октябрь"] = 10,
    ["сентябрь"] = 9,
    ["февраль"] = 2,
    ["январь"] = 1,
}
Only twelve month names when there should be twenty-four; the month-names from your example are among the missing.
The template worked when I rewrote the date as |date=2 ноябрь – 21 декабрь 1968.
What happens when you set local_date_names_from_mediawiki = false;?
—Trappist the monk (talk) 19:54, 14 December 2023 (UTC)
Yes, this fix works! Thanks again :) Iniquity (talk) 19:58, 14 December 2023 (UTC)

author-link=/editor-link=

Hey all - I've noticed that when putting in crosswiki articles in link fields, the citation templates split out something like the following:

I was wondering whether it would be possible to add functionality for putting in a {{ill}} template instead - I think it would look a lot cleaner, especially when you have multiple authors with no page on en-wiki who are notable.

also still shows the need for a page here and look a lot better than

What do you think/is this already possible?  Frzzl  talk; contribs  15:15, 17 December 2023 (UTC)

Previous discussions:
—Trappist the monk (talk) 15:33, 17 December 2023 (UTC)
Thank you very much for the quick response - I can see now why it's the way it is.  Frzzl  talk; contribs  15:49, 17 December 2023 (UTC)

Lay url thingies

They have been disputed since 2022. I've tried to use one to integrate a new URL on TRAPPIST-1, but it didn't work. Is it worth removing the section? Jo-Jo Eumerus (talk) 17:22, 17 December 2023 (UTC)

|lay-url=, |lay-source=, |lay-format=, and |lay-date= are no longer supported. I don't know what you mean by Is it worth removing the section? What section? Where?
—Trappist the monk (talk) 17:32, 17 December 2023 (UTC)
I'm not sure where it's transcluding from, but the documentation for Template:Cite journal (e.g.) still includes a subheading "Lay summary" with the deprecated parameters. The Help: page is clean of mentions. Folly Mox (talk) 17:59, 17 December 2023 (UTC)
Yeah, we shouldn't be documenting parameters that we no longer support. I've deleted mention of the |lay-*= parameters from various template doc pages and deleted the associated doc template.
—Trappist the monk (talk) 18:54, 17 December 2023 (UTC)

pages totales

In this edit, AnomieBOT substituted {{Ouvrage}} for {{cite book}} without updating |pages totales=204, which added the comment "auto-translated by Module:CS1 translator". In this edit, Citation bot then changed |pages totales=204 to |pages=204, which added the article to Category:CS1 errors: dates. Finally, in this edit, a kind editor removed the parameter. It seems like the correct thing to do would be for the Module:CS1 translator to remove |pages totales= because {{cite book}} does not have a parameter to indicate the total number of pages in the book. Is this the proper place to report this issue, or is there somewhere better? Thanks! GoingBatty (talk) 05:53, 18 December 2023 (UTC)

Module:CS1 translator does not translate non-English parameter names when there is no matching English parameter. Because cs1|2 does not support |total-pages=, |pages totales= does not get translated. It is left to the editors of the article to decide what to do about untranslatable parameters.
Similarly, because it is relatively easy to translate month names, that is all that the translator does for dates: |consulté le=04 juin 2018 gets translated to |access-date=04 June 2018. Again, it is left to article editors to decide what to do about the resulting error.
It is wrong for Citation bot to convert |pages totales=204 to |pages=204 (semantically incorrect – page 204 is only one page) when the template also has |page=41 as your example shows. You should take this up at User talk:Citation bot. The Citation bot edit did not add the article to Category:CS1 errors: dates but rather, added the article to Category:CS1 errors: redundant parameter.
—Trappist the monk (talk) 15:07, 18 December 2023 (UTC)
@Trappist the monk: Thank you for the suggestion. Marked  Fixed at User_talk:Citation_bot#pages_totales. GoingBatty (talk) 20:16, 19 December 2023 (UTC)

Number in author name

Is there a way to suppress the "CS1 maint: numeric names: authors list (link)" warning for something like |author=Jcmoore62 when citing social-media stuff? Also there is a notable journalist named Jennifer 8. Lee.  — SMcCandlish ☏ ¢ 😼  12:12, 20 December 2023 (UTC)

Try "take as written" ((…)): Jennifer 8. Lee. title. -- Michael Bednarek (talk) 12:23, 20 December 2023 (UTC)
@SMcCandlish:  Fixed the Jennifer 8. Lee article via the "take as written" solution above. You can also use {{cite tweet}} with |user=Jcmoore62 to avoid this issue, and reserve the |author= parameter for their real name (if known). GoingBatty (talk) 18:04, 20 December 2023 (UTC)
Ah, yes, the ((...)) trick. I'd forgotten about that.  — SMcCandlish ☏ ¢ 😼  20:51, 20 December 2023 (UTC)

Generic title

Per Category:CS1 errors: generic title I would like to report a generic title. In St Richard's Catholic College, there is the generic title "Register " present however it is not being reported as a generic title error. — MATRIX! (a good person!)[citation unneeded] 19:33, 21 December 2023 (UTC)

I thought this would have a lot of false positives, but these all (or almost all) look like errors to me. – Jonesey95 (talk) 22:16, 21 December 2023 (UTC)
Ugh just looking at the first page of those results makes me miss bare URLs. Folly Mox (talk) 05:16, 22 December 2023 (UTC)

doi outputting encoded value

Hi, in ticket:2023121410001737 a requester brought up that doi links are getting their "/" changed to "%2F" in the generated link, causing accessibility issues with certain browsers. Is this a new behavior? Ping to @Trappist the monk: who recently worked on the module. Possible related to phab:T353920? — xaosflux Talk 11:35, 22 December 2023 (UTC)

I cannot read ticket:2023121410001737 so cannot know what your correspondent is actually complaining about. Is this about the url itself or about the associated label? If they have complaints about how cs1|2 renders anything, this talk page should be their first stop.
Some sort of uri-encoding of the doi value has been used in the cs1|2 modules since at least this edit 25 August 2012 (url-encoding in {{doi}} was added at this edit 6 May 2008. We currently use mw.uri.encode (<doi>, 'PATH') to percent-encode the doi value because any ISO/IEC 10646 character may be used in a doi including characters that have specific meaning in a url. The label is not percent encoded but we do use mw.text.nowiki (<doi>) on the label portion of the extlink to replace certain characters with their html-entity equivalents (this 'nowiki-ing' is not limited to |doi= but applies to all identifier extlink labels).
The problematic code that caused phab:T353920 has been reverted so I don't know if your correspondent is complaining about that.
If none of this answers your correspondent's issues, tell them to post here; having a third party passing messages back and forth only confuses things.
—Trappist the monk (talk) 15:32, 22 December 2023 (UTC)

@Trappist the monk thanks for the note, the reversion didn't change things. This may be a problem in one of their niche browsers, and doesn't seem to be about anything you've recently done - just pinged you because you have recently worked on this template in case I missed something - or if you have special insight in to the issue.

Here's what is being seen, not sure if there are drawbacks to changing this:

  • Given a doi identifier such as 10.1109/TII.2019.2956078 (example here):
    • Many places link this to: https://doi.org/10.1109/TII.2019.2956078
    • However our cite templates links it to: https://doi.org/10.1109%2FTII.2019.2956078
  • Apparently some browsers have issue following the link in that format. — xaosflux Talk 15:46, 22 December 2023 (UTC)
What are we supposed to do about that? cs1|2 cannot know the user agent that is viewing our content. I suppose that MediaWiki knows but that information is not available to Scribunto. We might, after uri-encoding, 'decode' the single %2F between the doi-prefix and the doi-suffix to /. Is it worth the effort to make that happen? How niche is your correspondent's browser? Is it new? Is it old? How many readers of en.wiki (or the many other Wikipedias that use this module suite) use this niche browser? Has your correspondent discussed this issue with the browser manufacturer?
—Trappist the monk (talk) 16:16, 22 December 2023 (UTC)
We've asked - awaiting reply. I suspect this is likely a nothingburger, but wanted to check in just in case something recent caused a breakdown on our side (especially in light of that other parser bug). — xaosflux Talk 20:23, 22 December 2023 (UTC)

Allow setting doi-access to registration or limited

It has come to my attention that some people have been using doi-access=free in citations for works which are not open access but which occasionally offer some gratis access method, such as an intermittent bronze OA (non-libre gratis OA) status or the possibility for some people to register or go through other authentication walls, without payment, to access the full text. Such use is clearly contrary to the documented definition of "free", which says "free to read for anyone" (emphasis added), and which is distinct from the value "registration" for the case where "a free registration with the provider is required".

However, I have sympathy for the argument that there's been some confusion so far, and that the absence of doi-access=free is sometimes misinterpreted as a positive statement of something it's not. The easiest way out would be to allow adding doi-access=limited and doi-access=registration as we do for url-access. That would allow users to manually set this value to indicate the gray area situations. It would also allow us to finally default a blank doi-access to mean "subscription", and to show the red lock by default. Nemo 11:20, 30 November 2023 (UTC)

I could see adding |doi-access=registration as a valid access indicator (and I think this might help with some of OAbot's unaddressed misbehavior), but |doi-access=subscription is like |url-access=free. I would not want to see bots adding zillions of understood default access indicators, or their associated lock icons in reference lists, which would be the outcome of enabling the specification of the default value. Folly Mox (talk) 11:56, 30 November 2023 (UTC)
Good point, I mixed up. I meant it should be possible to explicitly set it to registration or limited, while "subscription" would be the default (still considered an error if added explicitly, as it is now). Nemo 11:59, 30 November 2023 (UTC)
The case I highlighted which started the discussion referred to by Nemo is doi:10.1001/jama.2009.405. There seems to be a difference of opinion whether this can be described as doi-access=free. My interpretation is that this source is indeed compliant: the webpage that is the target of the doi has the full text and that text can be downloaded by simple copy-paste, if the reader so desires. (To download a .pdf a user must provide their email address.) I don't see this as a grey area: citations are there in Wikipedia articles so that readers can verify that the source supports the text and using doi-access=free makes the title of the work a direct link to the place that the text is hosted and can be read by anyone. Mike Turnbull (talk) 12:03, 30 November 2023 (UTC)
To avoid more important work, I verified that the full article and all figures and tables present in the PDF are duplicated on the webpage. The only content lost is the page numbers. I think I'd characterise this as "free to read for anyone" and hence a poor example, but the problem described may actually exist: dois that offer only a preview for all viewers, but access to the full source for non-pay-for registered accounts. Folly Mox (talk) 12:33, 30 November 2023 (UTC)
I've seen OABOT removing many doi-access=free tags today from articles that appear to be completely free to read on the publisher's web page. I think we should leave those tags in place, because they are free to read. As you say this should only be for works where the full work is viewable, but I don't think freedom to reuse under an open license is relevant or necessary. —David Eppstein (talk) 23:14, 2 December 2023 (UTC)
Agreed. I just saw one of those, too.  — SMcCandlish ☏ ¢ 😼  11:32, 3 December 2023 (UTC)
And reverted it.  — SMcCandlish ☏ ¢ 😼  12:46, 3 December 2023 (UTC)
@Nemo bis Here's another removal that is perhaps understandable if you are a bot rather than a human. The relevant doi is doi:10.1016/0016-5085(92)91094-K. Click the link and it will open the actual article on the website. However, the URL is interesting: https://www.gastrojournal.org/article/0016-5085(92)91094-K/pdf?referrer=https%3A%2F%2Fwiki.riteme.site%2F includes the fact that this is has been a request from wikipedia! If you use the link https://www.gastrojournal.org/article/0016-5085(92)91094-K/ in a browser tab not associated with Wikipedia, you get to the publisher's web page, where there is a comment saying that the paper is only available as a .pdf. Humans can read that advice and do indeed get free access to the .pdf with one more click. Mike Turnbull (talk) 14:08, 3 December 2023 (UTC)
There was no excuse at all for this removal for doi:10.1139/v84-243 and I urge you to stop the bot immediately and revert all such removals. It might be better to permanently disable all free -> blank interventions and focus on the more useful blank -> free. Mike Turnbull (talk) 14:29, 3 December 2023 (UTC)
I'm not sure how this is relevant to this discussion. Anyway, the bot has already stopped removing doi-access=free. Can we go back to whether we can use doi-access=registration or doi-access=limited where the publisher requires login? JSTOR comes to mind, but I can find more examples if useful. Nemo 21:47, 3 December 2023 (UTC)

Here are some example DOIs from the JSTOR prefix, which are currently cited with doi-access=free but actually require registration: doi:10.2307/1378152, doi:10.2307/3632910, doi:10.2307/3496680, doi:10.2307/2324301, doi:10.2307/2371798. On phabricator:T344114#9392971 you can see how they're displayed to me. How are we supposed to mark these? Do I have to go through the entire registration process to check whether I will actually be able to read and download the file without paying? And how will I know that the requirements are the same in another country? Nemo 14:31, 8 December 2023 (UTC)

Please make the values of this |doi-access= be consistent with |url-access=. A |url-access=registration means a free registration while |url-access=subscription means a paid one. Needs to be the same for DOI. A JSTOR DOI is not free-registration but subscription-required.  — SMcCandlish ☏ ¢ 😼  22:10, 17 December 2023 (UTC)
I'm a bit confused here. The first two DOIs linked above don't even resolve to Jstor for me. They go to ucpress and oup. In my region, Jstor offers the option to sign up for a free personal account which will allow for reading "100 articles per month", and downloading zero. I have no idea how to determine whether any given article would be part of their "free reading" subset or still paywalled for institutional subscriptions only, or if such a stratification even exists. I note without additional relevant comment the |jstor-access= parameter, which I'm not sure I've ever seen used in the wild, although I've added it myself once or twice. Folly Mox (talk) 00:45, 18 December 2023 (UTC)
This is why we need to include the jstor= parameter even when we have a doi that looks like it comes from jstor. I see the same as you, UCP and OUP on the first two links. But (on my home IP address, at least) I don't have access to the OUP and UCP, and I do have access to jstor. So I would be able to read those references much more easily with a jstor= link than with a doi= link. —David Eppstein (talk) 00:53, 18 December 2023 (UTC)
Indeed "JSTOR prefix" is a simplification, as many of those DOIs belong to some publisher which presumably had an agreement with JSTOR. When the publisher is the destination of a 10.2307 DOI, usually that's because they're trying to sell access, and therefore JSTOR doesn't provide an open access copy. Restrictions on such works, even when one lands directly on the JSTOR side, are constantly changing. Therefore a doi-access=free is misleading. Nemo 14:38, 31 December 2023 (UTC)

Another example: a journal which requires you to register and remain subscribed to a newsletter in order to receive a PDF copy by email (phabricator:F41641477). Apparently the journal markets itself as open-access (and it used to be around 2022). Possibly a doi-access=registration would be warranted (but I've not checked whether registering actually provides access). Nemo 14:38, 31 December 2023 (UTC)

Successions of REF-plus-Rp pairs

Not a Cite template matter, but one to which Cite template experts might know an answer.

I have perpetrated a sentence, which, thanks to four reference+Rp pairs, ends, quote, [5]: 128–131, 141–143 [11]: 46 [2]: 111–114 [3]: 301–302, 304–305, unquote. (With some underlining and slightly different coloring.) Now, I know that this should be understood as something like [5] 128–131 & 141–143; [11] 46; [2] 111–114; [3] 301–302 & 304–305; but most readers may not. Any suggestions on how to make it easier to understand (and less horrid)? (And yes, I do realize (i) that having more than two references for a single assertion is usually poor practice and often is a doomed attempt to make up for the feebleness of each of those cited sources; and (ii) that 5, 11, 2, 3 is not the best order for them.) -- Hoary (talk) 09:10, 16 December 2023 (UTC)

This to me is a very clear case where WP:CITEVAR ("let a thousand flowers bloom") should be ignored and the citation style changed to Harvard (using {{sfn}} or {{sfnp}}). That would still give you six cite references (!) but at least they would be less obviously prolix.[51][52][110][31][32] Mouse over on each would reveal the source and page number e.g. Livingstone (1871) 128–131. 𝕁𝕄𝔽 (talk) 16:53, 16 December 2023 (UTC)
It's not clear to me why you would want to use six {{sfnp}}s where four would suffice, with two including multiple page spans. There is of course the alternate solution {{sfnmp}}, which has slightly weird syntax, sounds like a noise your pet might make immediately prior to generating a cleanup task, and leaves the prose with a single reference. Another way to do that is stack a bunch of {{harvnb}}s inside a pair of ref tags, separated by semicolons or periods.
But yeah when your clicky numbers start looking like this, your citation style has been pushed beyond its capacity and it's time to toss in some shortened footnotes. Folly Mox (talk) 23:58, 16 December 2023 (UTC)
This is a perfect example of why {{rp}} is an abomination and should never be used. —David Eppstein (talk) 00:40, 17 December 2023 (UTC)
As the creator {{rp}} (back when it was actually necessary due to lack of alternatives for particular cases), I would agree that it is obsoleted by methods like those described here, and in more complex cases by |ref=, as I "tutorialized" over here. (Though some of that can also be pulled off by use of existing templates, there are so many, so unclearly named, that I sometimes prefer to just use |ref=Smith2023 and <ref name="Smith2023 p123">[[#Smith2023|Smith (2023)]], p. 123. Optional annotation here.</ref>.) I'm not really sure how to go about deprecating and replacing {{Rp}}. Probably would need really good documentation on alternatives, and how to do conversion from it to a variety of practical and in-use, modern citation approaches.  — SMcCandlish ☏ ¢ 😼  16:44, 17 December 2023 (UTC)
One thing that would facilitate deprecation of {{rp}} (59073 transclusions), that is actually relevant to this page, would be some general way for "entire span of pages" and "specific page(s) supporting cited claim" to coexist within a citation template without the inclusion of a quote. This functionality would obselete all uses of {{rp}} where the source is an article or chapter and only one place in the source is used to support any article prose. (Additionally, this would give the "total length of work" bibliographic detail often created by scripts for gbooks refs a parameter to live inside that doesn't make it look like the cited claim is sourced to the final page of the index.)
The ideal would require dev support, but being able to add a loc parameter to named ref tags would basically completely duplicate {{rp}}'s functionality, although where to display the value held in loc in the on.hover / on.tap popup might get a little bit messy if the named ref contains anything other than a single citation with no postscript. Folly Mox (talk) 17:21, 17 December 2023 (UTC)
Hmm, but {{rp}} doesn't relate to any distinction between "entire span of pages" and a specific page or page-range being cited; it is just like |page= or |pages= in being specific, and differs from them in living outside the cite template so that different pages in the same source can be cited, because {{cite book}} or whatever can have only one of |page= or |pages=. We have a whole pile of shortened-footnote templates that support page numbers down and do this without leaving :113–123 "droppings" all over the article text. Having a separate parameter for total pages in the work wouldn't affect this in any way. It's been proposed before to have such a parameter, but it's been rejected because that's not citation information but bibliographical catalog information of no use to finding and verifying the source, any more than a parameter for size or for paperback vs. hardback or for unrevised printing/impression of the same edition. If there are user scripts and other tools mistakenly putting total page count into |pages= they need to be fixed to stop doing it (chief among them being CitationBot, which has been doing this to journal article citations, even up to replacing specific-page citations with full-page ranges, which is doing outright violence to the citation). I think you're proposing to change |page[s]= to be for that total-pages purpose and a new |loc= (how would that differ from |at=?) to take over the specific-page-citation function, which would mean that all of millions of citations with a page cited would have to change. A |loc= would be confusable with publisher's |location=, too. Plus, if we try to depend on changes to <ref> coming, we'd be waiting many years. Now I sound like a just a very dedicated naysayer. [sigh]
Getting rid of {{rp}} is really a matter of replacing it and citations using it with other templates ({{sfn}} and {{harvp}} and all the too-many variants of these things); it's primarily a matter of documenting how to do it in really simple terms for each kind of case. A lot of work up-front for someone, but most of the conversion work could be done by AWB users, across large swath[e]s of articles, after it's documented (and well enough to account for weird cases).  — SMcCandlish ☏ ¢ 😼  22:05, 17 December 2023 (UTC)
Well, the idea of loc was for use inside ref tags, and I agree that it would not be an appropriate name for a parameter inside a citation template. Perhaps I should just drop that idea entirely since it's a phab task anyway, and unlikely to get buy-in, etc.
Briefly, there is one use case for {{rp}} that would be obseleted by a |total-page-span=: the case when a source is cited only once, but is identified in the full citation with a page span (like a book or chapter), and doesn't include a quote (which would allow for the use of |quote-page=, already implemented). This parameter could help protect citations against Citation bot and others that find it somehow beneficial to replace page citations with the full page span of the source (which is damaging). Anyway, this wouldn't help much, and it's probably not the way to go, so apologies for the digression. Folly Mox (talk) 00:56, 18 December 2023 (UTC)
No wories, and sorry I didn't get that you meant <ref loc="something"> Honestly, I've never actually encountered |quote-page= in real-article use, so I'm not sure it would factor much into the {{rp}} mess or its cleanup. Doing my part, I did eliminate an {{rp}} just now, though; like swatting a mosquito. I've been pondering how to document a "Getting rid of Template:Rp" process; I guess no one else is going to do it, and I'm ultimately the Frankenstein responsible for that monster in the first place.  — SMcCandlish ☏ ¢ 😼  02:33, 18 December 2023 (UTC)

Thank you for all the commentary, peeps. I've never liked either adding or digesting these alternatives to REF+Rp, but I should reconsider them afresh. -- Hoary (talk) 08:47, 17 December 2023 (UTC)

I ran into a problem like that while working on Newton's laws of motion. By the nature of the topic, a statement is likely to have many equally good and accessible references, most of which are books that are thick enough to make page numbers more than a convenience. Moreover, each book will be cited in multiple places, with different page ranges for each. I didn't want to abandon the existing reference style, so I ended up writing manual footnotes with {{refn}}. That let me break up the reference-{{rp}} pairs with author names and other information like quotes from the relevant pages.
The methods described above all have their virtues. Any one of them could probably work, as long as your passion for proper referencing shines through. :-) XOR'easter (talk) 16:09, 17 December 2023 (UTC)
IMHO, this is a perfect poster child for hierarchical references, e.g., an |under= parameter that makes a citation subordinate to another, named, citation, possibly with sorting of the subordinate citations at a given level. I'm not sure whether that's doable as an extension of the existing <ref>...</ref> and {{cite}} or whether it would require new templates (CS3?). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:19, 29 December 2023 (UTC)
@Chatul: This is something the WMF have been attempting to bake into the underlying technology for years. See [7] & [8]. They have some demos working but haven't implemented support for the Visual Editor, iOS app, Android app, or ProveIt yet. Rjjiii (talk) 20:00, 29 December 2023 (UTC)

Expanding exemptions to CS1 error categories

Can pages beginning Wikipedia:Articles for deletion not be placed into the CS1 error categories? This would affect around 281 pages, as well as preventing new AfDs and new error modes from populating. Editing closed AfDs to fix errors is considered annoying. Folly Mox (talk) 15:54, 25 December 2023 (UTC)

I would not support this change, if it were technically reasonable to do. Editors are welcome to leave such articles in error categories until the AFD is concluded, or fix the errors in order to improve the article while it still exists. One way to get articles out of AFD is to improve them, as long as the subject is notable. – Jonesey95 (talk) 21:53, 25 December 2023 (UTC)
I was thinking of the actual AfD discussion pages (prefix:"Wikipedia:Articles for deletion"), not the articles themselves that are under discussion (Category:Articles for deletion). Folly Mox (talk) 22:39, 25 December 2023 (UTC)
My mistake. I still would not support this exception. Just fix the error and move on. – Jonesey95 (talk) 19:43, 26 December 2023 (UTC)
Meh. I've 'fixed' lots of WP:AFD discussion pages and similar discussion-like pages in Wikipedia and other non-article namespaces with |no-tracking=yes with never a complaint. That 'fix' leaves the broken cs1|2 template broken but gets the offending page out of whatever category.
—Trappist the monk (talk) 23:18, 25 December 2023 (UTC)
Sounds like as long as I'm not blowing up watchlists with high volume fixes like MalnadachBot, this task is acceptable to perform. I work pretty slow, so not too concerned.  Request withdrawn. Folly Mox (talk) 21:46, 26 December 2023 (UTC)

Citing an "unpublished" MS

-- is of course published, thanks to Libraries Tasmania, even though not conventionally published. And while we should reject sources that lack editorial oversight (etc), this MS is, I presume, a decent reference for any claim that it says this or that (even though I find the damn thing near indecipherable). But I don't think its title is "Diary of Kezia Elizabeth Hayter"; it simply is her diary (or part(s) thereof); and the library's MS number NS202-1-1 ought I think to be easier to see. Yet there's no "Template:Cite manuscript", or, as far as I know, anything similar. Am I missing anything here? (If I stick with Cite web, can I improve on my use of it?) -- Hoary (talk) 23:55, 25 December 2023 (UTC)

I don't think that I would use that source as a source (perhaps further reading...) because Wikipedia does not care what the subject says or wants to say about itself, no editorial oversight, etc. But were I to use that source, I'd stick with {{cite web}} but instead of |via=, |website=; I'd reduce the title so as not to be redundant; include |date=:
{{Cite web |last=Hayter |first=Keziah Elizabeth |date=1842 |title=Diary |website=Libraries Tasmania |url=https://stors.tas.gov.au/AI/NS202-1-1}}
Hayter, Keziah Elizabeth (1842). "Diary". Libraries Tasmania.
—Trappist the monk (talk) 00:30, 26 December 2023 (UTC)
Trappist the monk, I think the use of the diary (in Kezia Hayter) is OK. (Just don't ask me to ruin my eyesight and tire my brain attempting to read it.) But others are free to disagree and to act on their disagreement. Thank you for the formatting advice; I've adopted it, mostly. -- Hoary (talk) 01:16, 26 December 2023 (UTC)
(For my own edification, what does 'MS' expand to here?) Remsense留 01:20, 26 December 2023 (UTC)
Manuscript. isaacl (talk) 01:27, 26 December 2023 (UTC)
Thank you kindly. Remsense留 01:28, 26 December 2023 (UTC)

It is a WP:PRIMARY source, acceptable in moderation. There is also {{cite document}} which provides for the |type=file and link the URL in the |id= :

Hayter, Keziah Elizabeth (1842). "Diary of Kezia Elizabeth Hayter" (File). Hobart A 243 3: Libraries Tasmania. NS202/1/1.{{cite document}}: CS1 maint: location (link)

Probably best to use the full name of the file on location in the library. I also added the library location. -- GreenC 01:29, 26 December 2023 (UTC)

That seems very helpful, but I'd noticed Template:Cite document and had rejected it as intended for "short, stand-alone, off-line documents", which I took to mean individual letters, leaflets, posters and so on, rather than for anything with dozens of pages. -- Hoary (talk) 01:54, 26 December 2023 (UTC)
Could you also use |type= to hold "diary" and the title for the item number:
  • Keziah Elizabeth, Hayter (31 December 1842). "NS202-1-1". Libraries Tasmania (Diary).
  • {{cite web |last=Keziah Elizabeth |first=Hayter |type=Diary |title=NS202-1-1 |date=31 December 1842 |website=Libraries Tasmania |url=https://stors.tas.gov.au/AI/NS202-1-1}}
Rjjiii (talk) 03:58, 26 December 2023 (UTC)
Hoary if your concerned by the "short" qualifier in cite document, you should be even more concerned by "cite web", since the document is not available on the web. I'm not sure who wrote the documentation for "cite document" or why they added a "short" qualifier, but IMO that qualifier makes no sense for a couple reasons. More important is the "offline" factor and the template is better designed for unpublished documents held in library collections. -- GreenC 17:41, 28 December 2023 (UTC)
Short because of the way that the {{cite document}} template renders – title is rendered in a quoted upright font like a book chapter, a journal/magazine/newspaper article.
...IMO that qualifier [(short)] makes no sense for a couple reasons and then fails to enumerate those reasons. Sigh.
—Trappist the monk (talk) 20:11, 28 December 2023 (UTC)
For one, if/when there is a dispute, no one will agree what "short" means, it's a recipe for conflict - such as the wars over "short" categories.
Also, isn't the "title rendered in a quoted upright font" the same as the cite web template, like in the example above?
Bigger picture, we currently have no agreed on method for citing documents in archives eg. 1,000 documents in the The Ernest Hemingway Collection held at the JFK Presidential Library. How do we cite one particular document that is only accessible by an in-person visit, like a personal letter he wrote. If you say {{cite document}} then it really makes no sense to differentiate based on an arbitrary and subjective size of the document. Documents like that, regardless of length, are not usually in italics anyway, because they are unpublished. -- GreenC 20:57, 28 December 2023 (UTC)
Short as in 'article length' (upright quoted) v long as in 'book length' (italic); more-or-less in keeping with the minor/major works distinction described at MOS:TITLE. Documents cited with {{cite document}}, unlike unpublished holdings in an archive are expected to have been published hence the requirement for |publisher=.
For citing some document in some box on some shelf in some archival collection at some institution, we have {{cite archive}} (not a cs1|2 template but it renders more-or-less like a cs1|2 template). Such sources, of course, are likely not WP:RS.
—Trappist the monk (talk) 23:17, 28 December 2023 (UTC)
{{cite archive}} ok great I didn't know about that one. That is exactly what the diary is. It's a WP:PRIMARY source. The rule says it must be "reputably published", and WP:PUBLISHED (part of WP:RS) says it must have been made available to the public somewhere, which it has been at the Tasmanian library. It also depends how the source is used. In this case there is a quote from her diary that doesn't support any original conclusion by Wikipedia, rather she describes her upbringing, it is sort of like an old photograph, to demonstrate what a person looked like. Anyway User:Hoary, it's not too important but IMO {{cite archive}} is the way to go with this one, but your choice however you like. -- GreenC 18:48, 29 December 2023 (UTC)
GreenC, "short" did surprise me too. But I've just now downloaded the file, all 49 MiB and 173 pages of the intermittently decipherable thing. At the page whose address I specified, there's a "Download" link. (No, I do not intend to attempt to read the PDF. This is not "my" article.) -- Hoary (talk) 07:24, 29 December 2023 (UTC)

Automating conversion of REF-plus-Rp to Sfn((m)p)

A thread above, "Successions of REF-plus-Rp pairs", in which I asked about whether it was possible to make consecutive pairs (or threes, or fours....) less hideous, seemed to reach a general consensus that, now that it has better alternatives, Template:Rp is horrid and should almost never be used.

We all know that changing the citation styles of an article shouldn't be done without consensus, etc etc. In the article I'm primarily thinking of, it was me who first introduced Template:Rp; and since then the article has been very little edited by anyone other than me. So I'd have no qualms of conscience about doing away with this citation system and adopting an alternative. But I have massive qualms about the donkeywork needed. Is there perhaps some semi-automated conversion method? -- Hoary (talk) 02:01, 26 December 2023 (UTC)

I'm already working on a series of very complicated regexes to build into a user JavaScript, to normalize citation formatting well enough to then go through and search–replace {{rp}} (which is a monstrosity I created in 2007 when there wasn't an alternative) with replacements like {{sfnp}}. Because the community deprecated inline parenthetical referencing a few years ago, and {{rp}} is a form of inline parenthetical (albeit partial) referencing, it has to go; WP:CITEVAR is ultimately not going to be an issue, as long as the cleanup operation doesn't trample on otherwise legitimate citation styles. However, it is insanely difficult to parse XML (much less XML commingled with MediaWiki's novel {{...}} syntax), and developing and testing this scripting is going to take some time. Hoary, If you let me know what article in particular you want to de-{{rp}}-ize, I can use it as test data and thereby ensure it's one of the first pages cleaned up when the scripting is finished.  — SMcCandlish ☏ ¢ 😼  00:20, 29 December 2023 (UTC)
https://stackoverflow.com/a/1732454
I would use a mediawiki parser. Galobtter (talk) 00:25, 29 December 2023 (UTC)
I'm well aware of the difficulties and of that specific SO post, which has become a thought-terminating cliché at this point. It is about using regex to parse general-purpose XML/HTML broadly, while I need to account only for <ref>, and I do not even need to account for every imaginable possibility within its attribute values, just material that is likely in WP content, especially since editors are required to check the results before saving when using semi-automated tools; this is not a bot that will be doing things on its own. As for "use a mediawiki parser", like what?  — SMcCandlish ☏ ¢ 😼  00:40, 29 December 2023 (UTC)
mw:Alternative parsers might list one that is still maintained and suits your purpose. Folly Mox (talk) 01:12, 29 December 2023 (UTC)
Looks to be the sort of thing that, due to dependencies on particular languages (Python, etc.) or packages for them (node.js, etc.), would have to be built into a stand-alone web app, and couldn't be done as a script someone can just import into their common.js. Above my pay-grade. After I get something that generally works, someone else is free to re-develop it into something more fancy that maybe could handle any input no matter how mangled. I'm just testing for legit markup and likely error conditions, and will document known limitations, so people can do a round of pre-script cleanup to eliminate bad markup that is likely to cause a failure, like <ref name="foo"bar"> Can probably even build in some tests for such things. There's a thread on my user-talk page about this, for those who want to follow along.  — SMcCandlish ☏ ¢ 😼  03:43, 29 December 2023 (UTC)
Sure, but it really is much easier to make edits using a parser like https://github.com/earwig/mwparserfromhell (which I used for e.g. my lint error fixer bot). Life is easy when you can get every ref tag with two lines of code:
wikicode = mwparserfromhell.parse(text)
ref_tags = wikicode.ifilter_tags(matches = lambda node: node.tag == "ref")
And replacing all instances of a template is much more suited to a bot than an user script anyhow. Granted, a user script is easier to setup initially. Galobtter (talk) 18:11, 29 December 2023 (UTC)
SMcCandlish, the page I'd been primarily thinking of was/is English modal auxiliary verbs. Even for those who happen to like Rp it's a half-baked horrible mess: please don't tell me this; I know. ActivelyDisinterested guessed that the page I'd been muttering about above was that one and offered to do the conversion. I took AD up on the kind offer and explained why, in the short term, the converted version too really should be a mess. Eventually the article will be improved (I expect and hope) and then the messiness can be reduced. Another, similar article is English auxiliary verbs. If you'd like a guinea pig for alpha-testing a conversion technique, how about English auxiliary verbs? (NB If you have questions: Less than 20 hours from now I'll disappear from the internet; I'll be back two or three days later.) -- Hoary (talk) 07:43, 29 December 2023 (UTC)
That'll probably suffice as a test page. I've been refining the core regex stuff, and will start JS-chaining the regex operations probably tomorrow. (It certainly is impossible, even for a single multi-attribute element, to "munge" every possible configuration of it in a single regex; the StackOverflow post above is not wrong about that. Processing has to be done step-wise.)  — SMcCandlish ☏ ¢ 😼  07:57, 29 December 2023 (UTC)

Year

I have yearly periodicals, which the title is "World Air Forces 2024", published by FlightGlobal, and it was already published. That periodicals didnt explicitly states 'Date or Year of Publication', but there is a statement ©2023 FlightGlobal, part of DVV Media International Ltd in that periodicals. Which 'year' should I put on |year= parameter, 2023 or 2024? Ckfasdf (talk) 16:54, 26 December 2023 (UTC)

I would use 2023. The date in the title is unrelated to publication date (this is generally true in such cases, but definitely true in this case as the publication date cannot be in the future). You could also use n.d. (not dated), but I think it's clear it was published in this year. -- LCU ActivelyDisinterested «@» °∆t° 17:08, 26 December 2023 (UTC)
Thank you for your comment, that's what I thought as well. Also, I just learned about US copyright notice, whereas the year after copyright symbol means the year of first publication of the copyrighted work. Ckfasdf (talk) 17:39, 26 December 2023 (UTC)
I've seen past examples as the year the directory is for, but I'll opt to leave it blank and let the title speak for itsself FOX 52 talk! 23:00, 26 December 2023 (UTC)
Leaving the year blank would give false metadata and would be misleading as it would give the impression that it was written in 2024 - state the correct year (2023) in the template and in cites. In fact, for some of the uses, it should probably be explicitly stated in the text as to when the data is dated to - while the report was published in December 2023, the report states that the data was collated earlier.Nigel Ish (talk) 23:09, 26 December 2023 (UTC)
Agree and it was actually mentioned in page 11 of the report that the data was collated in 19 October 2023. Ckfasdf (talk) 02:36, 27 December 2023 (UTC)
Yep, and it's also important to remember that if |date= (or if you really insist on using it, the partially equivalent but easily broken |year=) is missing entirely, then templates like {{sfnp}} and {{harvp}} will not work, not without a custom |ref={{harvid|...}}. A date parameter should not be left off even when it seems "redundant" with something in the title of the article or the containing work.  — SMcCandlish ☏ ¢ 😼  00:33, 29 December 2023 (UTC)

DOI erroring

Why is the DOI erroring in this citation? It resolves correctly. czar 04:20, 27 December 2023 (UTC)

Are you sure it's really a doi? It looks more like a handle.
—David Eppstein (talk) 05:13, 27 December 2023 (UTC)
That looks right. Thank you! czar 05:15, 27 December 2023 (UTC)

in PDF doc citation, which page # to use?

If my citation reference is an online PDF document, which page # do I use? The page # that is printed on each page (could be i, ii, etc.) or the page # that my PDF viewer says I am reading. If the doc has an un-numbered title page & several i, ii pages, then the printed page could be 5 but the PDF page could be 10. I've tried to research this in WP but could not find the answer. Sunandshade (talk) 02:12, 28 December 2023 (UTC)

Printed on the page. Some (most) browsers recognize a page number added to the url as a fragment; see Wikipedia:Citing sources § Linking to pages in PDF files.
—Trappist the monk (talk) 02:28, 28 December 2023 (UTC)
Could you explain that a bit more? You say I should use the printed page #. But if I use <url>#page=n, that will be the PDF page #. I shouldn't use both, should I? Or maybe I should? Sunandshade (talk) 05:38, 28 December 2023 (UTC)
@Sunandshade: I see that you first asked this at Wikipedia:Teahouse#for PDF citation, which page # to use?. In the future, please don't post the same question in more than one place at the same time. GoingBatty (talk) 05:58, 28 December 2023 (UTC)
I'm new here & am learning the rules. Yes, I posted to Teahouse & was told there to post here so that's what I did. I was told the people here were experts in this area. In the future, if I'm told to ask in another place, what should I do? Can I somehow delete the original post so it's not in 2 places? Thanks for letting me know how things are done here. Sunandshade (talk) 06:36, 28 December 2023 (UTC)
@Sunandshade: Sorry, I missed the fact that someone at the Teahouse suggested you post here. My bad. Carry on... GoingBatty (talk) 06:38, 28 December 2023 (UTC)
This has been discussed before at Help talk:Citation Style 1/Archive 51#PDF page number different from document page number. I think the advice is to cite the printed page number, but if the citation includes a link, that should point to the PDF-internal page. -- Michael Bednarek (talk) 06:47, 28 December 2023 (UTC)
Right. To clarify: |page=[https://www.domain.com/document.pdf#page=5 4], rendering in the citation as p. 4. This technique is often needed for specific-page links to books on Internet Archive [other than the login-required "Borrow for 1 hour" ones, for which page-specific URLs are useless], because it uses a weird page-numbering system, e.g. p. iii of an introduction/foreword would be .../page/n3/... in the URL in many cases (but not consistently; I think it depends on who did the digitization).  — SMcCandlish ☏ ¢ 😼  03:50, 29 December 2023 (UTC)
I think I got it now. Looks like there are two (or more) ways of doing this. I think I'll use: |url=<addr>/fid.pdf#page=2|pages=906-907|title=Humans Using Pigment|website=Nature|access-date=2023-12-27
For the other option, I could use: |url=<addr>/fid.pdf|pages=[<addr>/fid.pdf#page=2 906-907]|title=Humans Using Pigment|website=Nature|access-date=2023-12-27
But that repeats the URL in the citation so clutters it up a bit. I tried to not use the 1st URL but it said I needed it since I had an access-date. Sunandshade (talk) 06:15, 30 December 2023 (UTC)
@Sunandshade: That sounds good. If I came across the citation I would have zero confusion about the explicit page number and the embedded page number. Good luck, Rjjiii (talk) 08:03, 30 December 2023 (UTC)

cite encyclopedia

This works:

{{cite encyclopedia |title=Энциклопедия Республики Марий Эл |trans-title=Encyclopedia of the Republic of Mari El |language=Russian |page=99 |year=2009}}
Энциклопедия Республики Марий Эл [Encyclopedia of the Republic of Mari El] (in Russian). 2009. p. 99.

This does not:

{{cite encyclopedia |encyclopedia=Энциклопедия Республики Марий Эл |trans-title=Encyclopedia of the Republic of Mari El |language=Russian |page=99 |year=2009}}
[Encyclopedia of the Republic of Mari El]. Энциклопедия Республики Марий Эл (in Russian). 2009. p. 99. {{cite encyclopedia}}: |trans-title= requires |title= or |script-title= (help)

The difference is |title= vs. |encyclopedia=.

The docs say the paring of |encyclopedia= + |trans-title= should work (I think). -- GreenC 17:34, 28 December 2023 (UTC)

{{cite encyclopedia}} is a pain in the ass. {{cite encyclopedia}} templates can be written in a variety of ways:
{{cite encyclopedia |article=Article title |encyclopedia=Encyclopedia title}} → "Article title". Encyclopedia title.
{{cite encyclopedia |chapter=Chapter title |encyclopedia=Encyclopedia title}} → "Chapter title". Encyclopedia title.
{{cite encyclopedia |contribution=Contribution title |encyclopedia=Encyclopedia title}} → "Contribution title". Encyclopedia title.
{{cite encyclopedia |entry=Entry title |encyclopedia=Encyclopedia title}} → "Entry title". Encyclopedia title.
{{cite encyclopedia |section=Section title |encyclopedia=Encyclopedia title}} → "Section title". Encyclopedia title.
{{cite encyclopedia |title=Title title |encyclopedia=Encyclopedia title}} → "Title title". Encyclopedia title.
{{cite encyclopedia |article=Article title |title=Encyclopedia title}} → "Article title". Encyclopedia title.
{{cite encyclopedia |chapter=Chapter title |title=Encyclopedia title}} → "Chapter title". Encyclopedia title.
{{cite encyclopedia |contribution=Contribution title |title=Encyclopedia title}} → "Contribution title". Encyclopedia title.
{{cite encyclopedia |entry=Entry title |title=Encyclopedia title}} → "Entry title". Encyclopedia title.
{{cite encyclopedia |section=Section title |title=Encyclopedia title}} → "Section title". Encyclopedia title.
Do we really need all of these ways to write an encyclopedia citation? In general, it seems, editors prefer to write {{cite encyclopedia}} templates with |encyclopedia=<Encyclopedia Title> and |title=<article/entry title>. Here are some searches:
  • number of articles that use some form of {{cite encyclopeida}}: ~62,100
  • number of articles that use {{cite encyclopedia}} where |title= precedes |encyclopedia=: ~44,300
  • number of articles that use {{cite encyclopedia}} where |encyclopedia= precedes |title=: ~10,500
The above do not include wrapper templates that wrap {{cite encyclopedia}} of which there are ~370.
Were it up to me, I would enforce that choice because it is more-or-less consistent with how {{cite journal}}, {{cite magazine}}, {{cite magazine}}, {{cite web}} are intended to work (yeah, you can write a {{cite journal}} template with |website= instead of |journal= which I think to be nonsensical...).
For your example the documentation (such as it is) is wrong. The correct parameter to match |encyclopedia= would be |trans-encyclopedia= which parameter does not exist (nor does |script-encyclopedia= which would be the correct parameter to use for Энциклопедия Республики Марий Эл).
—Trappist the monk (talk) 15:34, 29 December 2023 (UTC)
It's trouble for |title= to signify two different things - the title of the encyclopedia OR the title of the article in the encyclopedia. |title= should be an alias of chapter/section/entry/article - there would be only be one of those defined. The name of the encyclopedia would be |encyclopedia= or |work=. Or |title= is an alias of |encyclopedia=, one way or another, but not both at the same time. Is this controversial to repair? I would think most people would agree, an argument should have one meaning, not a double meaning, which is ambiguous. -- GreenC 19:31, 29 December 2023 (UTC)
I agree but don't agree. In {{cite journal}}, {{cite magazine}}, {{cite news}}, {{cite web}}, etc, |title= is the name of the article. Those templates don't support |article=, |chapter=, |contribution=, |entry=, or |section= so a rewritten {{cite encyclopedia}} template should not support them. Those parameters are all aliases of the {{cite book}} base-parameter |chapter= so if one of them is needed, the encyclopedia can be cited using {{cite book}} where |title= gets the name of the encyclopedia ({{cite book}} does not support |encyclopedia=).
If we rewrite {{cite encyclopedia}} we should:
  • require |title= and |encyclopedia=
  • add support for:
    • |script-encyclopeda=
    • |trans-encyclopedia=
  • disallow |article=, |chapter=, |contribution=, |entry=, and |section=
Given that most implementations of {{cite encyclopedia}} use |title= and |encyclopedia=, I expect that a rewrite of the template will not be too controversial. But then, who knows, it is also possible that someone will get their panties in a bunch and call down the torches and pitchforks...
—Trappist the monk (talk) 16:56, 30 December 2023 (UTC)
I'm OK with all that. Encyclopedia's are books, they sometimes have areas that don't easily fall into 'title of an encyclopedia article'. Such as chapters or sections that need to be referenced, such as a preface. On the other hand, such a situation may be rare, and in those cases it might be best to use {{cite book}}, since the encyclopedia template is designed for citing encyclopedia article entries, and not other book-like things it might contain on the margins. -- GreenC 17:36, 30 December 2023 (UTC)
How would such a re-write deal with current uses of |entry=, |entry-url=, and other similar parameters? -- Michael Bednarek (talk) 02:04, 31 December 2023 (UTC)
It would be necessary to run a bot or awb script over the ~62100 - (~44300 + ~10500) = ~7300 articles that use {{cite encyclopedia}} with some combination of |article=, |chapter=, |contribution=, |entry=, or |section= with |encyclopedia= or |title= to convert those templates to use |title= and |encyclopedia= before the {{cite encyclopedia}} rewrite can go live.
—Trappist the monk (talk) 15:44, 31 December 2023 (UTC)
I suppose I'm in the minority as usual, but when I call {{cite encyclopedia}}, I use |entry= and |title=. One reason is that since |encyclopedia= isn't an alias of |work=, the |trans-work= and |script-work= parameters don't work on it, while |trans-chapter= and |script-chapter= work on |entry=. Another is that my keyboard suggests "encyclopaedia" and variants as string autocompletions, so I have to type the US spelling "encyclopedia" in full every time (unless |encyclopaedia= is now a valid alias; it hasn't always been).
I agree that it's confusing that |title= is polysemic within this template, depending on whether it's paired with |entry= or |encyclopedia=, and one of the two modes should be sunsetted.
Perhaps to ensure equal satisfaction by all users, implementation could split the baby by dropping support for |title=, and requiring |entry= alongside |encyclopedia=. Folly Mox (talk) 02:44, 31 December 2023 (UTC)
|encyclopaedia= has been in Module:Citation/CS1/Whitelist from its first implementation (4 April 2013). For the sake of historical completeness:
  • |encyclopaedia= was present in the first implementation of Module:Citation/CS1 (19 February 2013)
  • Module:Citation/CS1 derives from Module:Citation where |encyclopaedia= was added to the module at this edit (26 August 2012)
  • the wikitext versions of {{cite encyclopedia}} did not support |encyclopaedia= so that parameter did not become available until the template was switched from wikitext to Lua at this edit (17 March 2013)
The ugliness of {{cite encyclopedia}} is already apparent in the first version of Module:Citation/CS1. At line 272 the Title metaparameter can get its value from |title=, |encyclopaedia=, |encyclopedia=, or |dictionary=. A few lines from there, at line 286, the Periodical metaparameter can get its value from |journal=, |newspaper=, |magazine=, |work=, |periodical=, |encyclopedia=, or |encyclopaedia=. Some of that has already been fixed: |encyclopedia= and |encyclopaedia= have their own Encyclopedia metaparameter and are only allowed in {{cite encyclopedia}} and {{citation}}.
—Trappist the monk (talk) 16:39, 31 December 2023 (UTC)
Given that an encyclopedia is a book, wouldn't the most sensible course of action be to use a bot to normalize all instances of it to be compliant with {{cite book}} parameters, and then just redirect {{cite encyclopedia}} to {{cite book}}? Seems like a sensible proposition to make at WP:TFD if you ask me. We have too many citation templates as it is. Same could be done with {{cite magazine}} → {{cite journal}}; we have no need of redundant periodical templates that are the same thing except having a different name for what sort of periodical it is.  — SMcCandlish ☏ ¢ 😼  00:55, 4 January 2024 (UTC)
SMcCandlish, perhaps it's marginal, but isn't a distinction here useful for categorization, since encyclopedias are tertiary sources and not as broadly appropriate as "books" in general? — Remsense留 02:06, 4 January 2024 (UTC)
Conceivably, though a lot of things with "Encyclopedia" in their titles are not actually encyclopedias and are secondary works. E.g. The New Illustrated Encyclopedia of Billiards is a work of predominantly secondary nature. And people use this template all the time for things that are dictionaries or other works, not encyclopedias. And lots and lots of tertiary works usually cited with {{cite book}} do not have "encyclopedia" (or "dictionary") in their titles. But what categorization would we be doing anyway? "Articles that contain citations to tertiary sources"? Is there an actual useful purpose to doing that? If there is, it would probably be better done with the {{Tertiary source}} template which is completely agnostic as to the title of the work or what {{cite foo}} template its details were shoehorned into. That add-on template already has some configuration parameters for various use cases, like tertiary sources that don't cite their own sources, tertiary sources that do provide a bibliography but don't cite individual sources specifically, and tertiary sources that are too weak for us to be using and should be replaced. It doesn't do any categorization yet, other than in the last case (too-weak tertiary source) "put the article in Category:All pages needing factual verification (or a dated subcat thereof), just like {{Primary source inline}} does". Adding more categorization to it would not be hard.  — SMcCandlish ☏ ¢ 😼  02:36, 4 January 2024 (UTC)
I had no idea about {{Tertiary source}}, thank you for the reply. Remsense留 03:09, 4 January 2024 (UTC)
This is not an objection but more a note for anyone cleaning up {{cite encyclopedia}} uses: I've used it before to cite online-only an encyclopedia like Wex (https://www.law.cornell.edu/wex). After reading this discussion, I tested {{cite book}} with |chapter-url= and {{cite web}} with |url=. Both render exactly the same, but cite web is much clearer in the wiki text. I don't know how cite book would affect the unseen data. Regards, Rjjiii (talk) 05:58, 4 January 2024 (UTC)
Which unseen data? Anyway, {{cite web}} could certainly be used as a replacement for {{cite encyclopedia}} cases that are Web-only publications. What this really comes down to is that {{cite encyclopedia}} is an odd-one-out, unnecessary template fork that has nothing to do with what medium/format the publication is, the way our most-used cite templates do, but is trying to address what "societal role" or "authorial purpose" the publication supposedly has. It's like forking a {{cite documentary}} from {{cite AV media}}, or forking a {{cite reality show}} template from {{cite AV media}}, or forking a cite {{cite festschrift}} from {{cite book}}, or {{cite space opera}} from {{cite AV media}}, or (surprise! someone did it!) forking {{cite magazine}} from {{cite journal}}. Even {{cite news}} should probably also be merged to the latter (which might need addition of |agency=). Several other templates listed in Category:Citation Style 1 templates are also pointless forks of this sort, though a few are arguably useful wrappers for addressing source types with particular ID formats, like {{cite arXiv}}. E.g. {{cite podcast}} is a pointless fork of {{cite AV media}} and could just be redirected to it (this would have the benefit of adding support for the "subscription or registration required" parameters which according to the documentation are lacked by {{cite podcast}}, though that may not actually be true in the code). {{Cite episode}} is likewise another unnecessary redundancy forked from {{cite AV media}}. It's noteworthy that various other things have already been merged/redirected, like {{cite film}} to {{cite AV media}}, {{cite e-book}} to {{cite book}}, etc.  — SMcCandlish ☏ ¢ 😼  08:35, 4 January 2024 (UTC)
The Wikipedia:COinS that CS1 templates make. I changed my Wex citation to {{cite web}} to make sure future updates don't make the online resource appear as a book somewhere. Rjjiii (talk) 18:50, 4 January 2024 (UTC)
Now I've gotten curious what the exact differences are. May have to go test this in a sandbox and find out.  — SMcCandlish ☏ ¢ 😼  04:45, 5 January 2024 (UTC)

new error-checking in "author"/"last" parameter?

Hi,

I get the impression someone's recently implemented checking for digits and other non-letter chracters in the |author= parameter... however, that seems to have missed or ignored the fact that {{cite tweet}} and {{cite Instagram}} (and possibly others) use it to hold usernames that do contain non-letters.

So basically you have a bunch of instances of those templates throwing errors. E.g.:

[1]

[2]

References

  1. ^ Rustad, John [@JohnRustad4BC] (December 25, 2023). "Merry Christmas from my family to yours. May the holidays be filled with love, peace and joy!" (Tweet). Retrieved December 30, 2023 – via Twitter.
  2. ^ Plummer, James [@movielover927] (2023-05-24). "Happy birthday to the best big brother in the world. I love you so so much. I hope you have an amazing birthday". Retrieved 2023-10-30 – via Instagram.

As a result, Category:CS1 maint: numeric names: authors list has many, many entries.

Could we maybe revert this new check? Or is there some way to tweak the two templates to not throw this newly defined "error"? —Joeyconnick (talk) 19:32, 30 December 2023 (UTC)

The sandbox version appears fixed though? @SWinxy, Nardog, and Joeyconnick: is there any issue with the sandbox code or can we move it to the live template? Rjjiii (talk) 20:34, 30 December 2023 (UTC)
*Sandbox version of {{cite twitter}}; {{cite instagram}} is different. Sandbox version of Twitter example:
Rjjiii (talk) 20:48, 30 December 2023 (UTC)
{{Cite instagram}} is a much simpler wrapper. Does just leaving the username out of the actual author parameter fix the error messages? Example from above:
And here's a bogus example with the date in the author field that should emit a message:
Rjjiii (talk) 21:31, 30 December 2023 (UTC)

Article titles

Am I correct in assuming the first letters of words in article titles other than conjunctions, prepositions, pronouns and similar words should be in upper case, so that in Visual Editor after a citation has been generated the title needs to be edited? I notice numerous citations where first letters are not in upper case. Mcljlm (talk) 21:25, 30 December 2023 (UTC)

Mcljlm, citations generated by the Visual Editor will often need editing from their initial state, not just because of improper capitalisation, but because it relies on the Citoid library, which has a tendency to produce citations to webpages that are total trash garbage, like:
{{cite web |last=Office |first=United Nations Press |date=[none given, despite prominent presence of the webpage] |title=United Nation Press Release – United Nations Press Office |website=press.un.org |access-date=[today]}} Folly Mox (talk) 22:36, 30 December 2023 (UTC)
More specifically about Mcljlm's question, no it is not necessary to rewrite an article title like "MP Jackson causes row over response to scandal accusations" or "Impacts and management of feral cats Felis catus in Australia" to read "MP Jackson Causes Row over Response to Scandal Accusations" or "Impacts and Management of Feral Cats Felis catus in Australia", unless a particular article is written in a WP:CITESTYLE that is imposing title case on all article/chapter titles (which is exceedingly unusual). Most journals and newspapers do not use title case for article names, so most such titles are in sentence case and it would take someone a lot of rather obsessive activity to "fix" all of them to be title case in a long WP article (and probably be met with reversion by other editors). The title cleanup to do is when someone has forced a book or journal's entire-work title to sentence case, e.g. The encyclopedia of scientific terms or Journal of cardiac surgery, since that is not the normal presentation of the title of such a work (even in citations that are consistently using sentence case for article/chapter titles).  — SMcCandlish ☏ ¢ 😼  00:47, 4 January 2024 (UTC)


Adding "Deprecated" sources from Wikipedia:Reliable sources/Perennial sources to a maintenance category

Wikipedia:Reliable sources/Perennial sources has a list of sources that the community has deemed unreliable and has given it a "Deprecated" status. I think it would be helpful if the module detected citations using a site from that list and add to a maintenance category. Gonnym (talk) 16:12, 3 January 2024 (UTC)

Just because I was curious, I hacked my module sandbox and created Module:Sandbox/Trappist the monk/deprecated sources. That module reads Wikipedia:Reliable sources/Perennial sources and extracts the deprecated domains that are listed in the Uses column of the Perennial sources table. My sandbox module creates a lua k/v table so that should we decide that this is a good idea, Module:Citation/CS1 can compare the domain in any of the url-holding parameter to the list of deprecated sources.
The list of deprecated domains can be seen at this version of my sandbox (permalink).
So long as the Perennial sources table remains organized more-or-less as it is now (Uses column to the right of the Status column) the sandbox module code should continue to work.
You will notice (before it gets fixed), that the journal-neo.org entry in the list is prefixed with its html scheme (it shouldn't be). Also, the Perennial sources table lists twenty domains for Sputnik. There are actually twenty-two listed in the Sputnik {{/Uses}} template, all appear in the list at my sandbox.
I gotta wonder if this is functionality is at all useful to other-language wikis. According to Wikidata, there are only 14 wikis that have some sort of Perennial sources page; most appear to be distinctly different from ours.
—Trappist the monk (talk) 00:10, 4 January 2024 (UTC)
Seems more like a job for a bot, and one that can be told by template to ignore particular citations. Any source may be reliable for a claim about itself per WP:ABOUTSELF, or for a person's claim about themself published as, e.g., the author of the cited article or as the interview subject, in a source that is otherwise not generally reliable (due to a particular strong political slant or whatever), also per the same ABOUTSELF policy. For some works, that are on our blacklist, citation of such sources has to be done with a whitelisting entry for the exact URL of the page in question, but most of the sources at RSP are not blacklisted. That is to say, a new Lua routine, whether built into CS1 or more appropriately used by a bot, cannot become a means of invalidating our whitelist or serving as an "alternative" blacklist that the community didn't approve.  — SMcCandlish ☏ ¢ 😼  00:37, 4 January 2024 (UTC)
A category "Articles with deprecated sources" or such could be useful for tracking purposes, but I'm not sure of any automation. Automation and referencing has caused so many issues. If this was a maintenance or error messages good faith editors might feel the need to 'correct' valid uses. Separately I not sure if it already exists or not, but a tracking category for blacklisted URLs (that aren't whitelisted) would also be useful. -- LCU ActivelyDisinterested «@» °∆t° 00:49, 4 January 2024 (UTC)
Agreed. I uncommonly run into them accidentally, stuff that was added before the URL was blacklisted. I'm not certain what triggers what, but it seems to me so far that if you edit such a page or section, nothing happens, but if you modify the citation then it re-triggers the blacklist. Maybe only if you update the URL-related parameter in some way, e.g. because the https://foo.bar/baz/quux/whatever.html structure of the site changed to https://foo.bar/baz/whatever.asp, or something in |url= needs to move to |chapter-url=, or whatever. It doesn't come up often enough for me to have tested it out.  — SMcCandlish ☏ ¢ 😼  02:47, 4 January 2024 (UTC)

Undocumented url-status values

Some other features document the use of additional values for url-status that aren't documented here. Most notably, "bot: unknown". I've marked the documentation for this template with {{Improve documentation}} per the instructions at that template. -- Mikeblas (talk) 00:40, 7 January 2024 (UTC)

When I listified the keywords acceptable to |url-access=, I intentionally omitted bot: unknown because that keyword defined for bot use only. When a bot has set |url-access=bot: unknown, cs1|2 emits a maintenance message with a link to Category:CS1 maint: bot: original URL status unknown where that keyword's meaning is described.
—Trappist the monk (talk) 13:56, 7 January 2024 (UTC)
Humans can see it when it is left behind by bots, and aren't able to learn what it means. If it is useful, it should be documented, even if only to say "this can be ignored". Or should this value be removed when it is encountered by a human? SMcCandlish, I see you removed the documentation tag. Are you able to explain what editors should do when they encounter url-status=bots: on a citation they are maintaining? -- Mikeblas (talk) 21:51, 8 January 2024 (UTC)
Per WP:MENTION, looks like I have to ping SMcCandlish again. -- Mikeblas (talk) 22:08, 8 January 2024 (UTC)
Like Trappist said, it's covered at Category:CS1 maint: bot: original URL status unknown. Maybe we just cross-reference it? We don't need to duplicate documentation of it one place at another, surely. Or am I just missing something? (I am actually tired, so that's very possible.)  — SMcCandlish ☏ ¢ 😼  22:17, 8 January 2024 (UTC)
Linking it might be fine, but some description would be great because that category documents the category, not the parameter. I went to the {{cite web}} documentation to try to figure out what url-status=bot: something meant, and what I should do with it. Lots of url-status=bot: unknown is around, for example, but that's not explained in the documentation. The title of the category doesn't even match: "bot: original URL status unknown" is different than "bot: unknown". And the instructions there aren't specific: "Editors should review these URLs and adjust the value assigned to |url-status= accordingly." I guess that means review them for an appropriate choice of the documented url-status= values? So then these "bot:" values are not just for bots, but for humans to go and fix? -- Mikeblas (talk) 23:19, 8 January 2024 (UTC)
I know this probably isn't helpful to hear, but it makes sense to me. When I see a piece of non-rendered code that mentions a bot or a module, that indicates to me that it wants its work double checked. On the other hand, it's probably not helpful to have any bots stating they don't know what the status of a url is, since it's functionally equivalent to "default" (which people don't agree on anyway). Folly Mox (talk) 04:38, 9 January 2024 (UTC)
Feel free to counter-revert my revert; I was just going by the idea that what Trappist said above was sufficient, but if you feel it's not, I don't feel strongly about it.  — SMcCandlish ☏ ¢ 😼  15:46, 9 January 2024 (UTC)
I've added some clarifying text to the documentation. (That meant reverse-engineering a couple of layers. The change I made ended up being at Template:Citation Style documentation/url). -- Mikeblas (talk) 01:58, 10 January 2024 (UTC)

Author credentials

Adding ", Ph.D, D.Prof" at the end of |first= generates "CS1 maint: multiple names: authors list". Template doc shows a |degree= parameter that is not supported. ―Mandruss ☎ 13:39, 7 January 2024 (UTC)

I like this behaviour. |degree= seems to be an alias of |type= specific to {{cite thesis}}, but more importantly no one should care what level academic degree the author of a published work has gained: most people who publish academically are going to be PhD or an analogous medical degree, and when books published by non-academic presses include "PhD" in the authorial attribution, what this usually signals is "unable to get this quackery past peer review" or "completely outside academic field of competence". Folly Mox (talk) 14:09, 7 January 2024 (UTC)
Indeedy.  — SMcCandlish ☏ ¢ 😼  18:38, 7 January 2024 (UTC)
Also, if one really must include the "PhD" in the authorial contribution, when adding it to the |first= parameter, simply omit the comma, just like with Jr. or Sr., and this will avoid the maintenance categorisation. Folly Mox (talk) Folly Mox (talk) 14:13, 7 January 2024 (UTC)
My particular example is this in Psychology Today. I don't know, but I doubt such publications are routinely subject to peer review. And I think it does matter that the author has some credentials in the subject area, which wouldn't necessarily be a requirement to write such an article. It strengthens the support for the content citing it. One could argue that his PhD might be in astrophysics or something, but it seems unlikely. ―Mandruss ☎ 14:21, 7 January 2024 (UTC)
Yeah, I was overly harsh in my characterisation of why publishers include the author's degree status. I've just seen it misused so many times to add credibility to material without credibility.
I think the linked publication is peer reviewed. I don't think most citations for that source would include the author's degree status, even though it's included in the byline, kinda similar how citing a news story wouldn't include "Senior Correspondent". Folly Mox (talk) 14:48, 7 January 2024 (UTC)
Key words being "kinda similar". "Senior Correspondent" is a job title, not a credential. ―Mandruss ☎ 15:01, 7 January 2024 (UTC)
I would see "Ph.D, D.Prof" or similar as an appeal to authority, as it's often used to try and pump the credentials of an author. I don't think it adds anything useful to the cite. -- LCU ActivelyDisinterested «@» °∆t° 14:52, 7 January 2024 (UTC)
Aren't all citations "appeals to authority"? Particularly in areas of science? ―Mandruss ☎ 14:58, 7 January 2024 (UTC)
No their a source for the purposes of verification. -- LCU ActivelyDisinterested «@» °∆t° 15:01, 7 January 2024 (UTC)
Verification by an authority in the subject matter. ―Mandruss ☎ 15:05, 7 January 2024 (UTC)
I suppose I could disclose at this juncture that while I've never sought them out disruptively or en masse, if I happen across degrees attained in an authorial attribution in the course of unrelated citation repair, I'll silently remove them as unnecessary.
I don't think I've ever read a published source that, in its bibliography, included degree status of any author. Sometimes people publish without any advanced degree, and no one thinks to add "BA" or "never graduated high school". Publishers will include an author's degree to add credibility to the written material, but there's really no point to including them in citations. Folly Mox (talk) 15:17, 7 January 2024 (UTC)
Fair enough. In this specific case, I'll leave the credentials in and assume that few enough editors have the maintenance error messages turned on (the citation is being used solely on an article talk page). It's part of a controversial proposal that needs all the help it can get. Otherwise, I haven't seen a lot of need for credentials in cites. ―Mandruss ☎ 15:25, 7 January 2024 (UTC)
(edit conflict)
Yeah, |degree= is only supported by {{cite thesis}} where it aliases |type= with additional static text. Ranks, degrees, titles (scholarly and aristocratic), post-nominals, and anything else that isn't the author's/contributor's/editor's/interviewer's/translator's name is all unnecessary cruft in a citation (generational suffixes excepted). Let the source flout those things if they think it important to do so.
—Trappist the monk (talk) 15:32, 7 January 2024 (UTC)
Yep. See also MOS:CREDENTIAL, MOS:HONORIFIC, MOS:POSTNOMINAL, etc.: WP doesn't use these things, except some of them in the lead sentennce and infobox on WP's article on the writer. PS: as for 'if one really must include the "PhD" in the authorial contribution, when adding it to the |first= parameter ...', one really mustn't, and needs to be aware that other editors will remove it on sight. PPS: The only maybe-exception, that is anywhere near this general realm of stuff, that I make is that if someone is "Reverend General Sir Xerxes Youill of Zounds, KBE, FSA(Scot), PhD, Esq.", and uses the long-form surname with "of Zounds" when publishing and is commonly referred to that way, I'll cite them as |last=Youill of Zounds|first=Xerxes (because it's consistent with de/du/di/von/van/etc. constructions in other languages). Some editors will probably object even to that, though removing it may make them ambiguous with other writers named (in this silly example) Xerxes Youill. A real example is Sir Thomas Innes of Learney, former Lord Lyon (heraldic authority of Scotland). I mostly see him referred to as Thomas Innes of Learney, not as Thomas Innes (except in a biographical article's material that covered his early life). Our own article on him uses both the long and short forms inconsistently, and WP isn't a reliable source anyway; I just follow the source usage.  — SMcCandlish ☏ ¢ 😼  18:38, 7 January 2024 (UTC)

Added TemplateData for Template:Cite document

I've just added the TemplateData for {{Cite document}}. Whatever this is supposed to do {{#invoke:cs1 documentation support|template_data_validate|{{ROOTPAGENAME}}}} just gives an error message for that template. I copied most of the parameters straight from {{Citation}} which was kind of tedious; is there a better way for other CS1 templates lacking TemplateData? Rjjiii (talk) 03:56, 9 January 2024 (UTC)

That {{#invoke:}} is for error checking the TemplateData parameter list against the module suite. Restored and lua script error fixed.
—Trappist the monk (talk) 15:21, 9 January 2024 (UTC)
Thanks! That made parameter trimming much easier, Rjjiii (ii) (talk) 17:28, 9 January 2024 (UTC)

support for |script-encyclopedia= and |trans-encyclopedia=

I have added support for |script-encyclopedia= and |trans-encyclopedia= to the sandbox. This answers lack-of-same that I mentioned at Help talk:Citation Style 1 § cite encyclopedia. The parameters are only valid in {{cite encyclopedia}} and {{citation}}:

{{cite encyclopedia/new |title=Title |encyclopedia=Encyclopedia |script-encyclopedia=ru:ScriptEncyclopedia |trans-encyclopedia=Trans Encyclopedia}}
"Title". Encyclopedia ScriptEncyclopedia [Trans Encyclopedia].
{{citation/new |title=Title |encyclopedia=Encyclopedia |script-encyclopedia=ru:ScriptEncyclopedia |trans-encyclopedia=Trans Encyclopedia}}
"Title", Encyclopedia ScriptEncyclopedia [Trans Encyclopedia]

—Trappist the monk (talk) 16:39, 9 January 2024 (UTC)

👍 Like. Will {{citation}} ever support |chapter= and pals? Or is that another thing that's actually supported and I'm the one doing something wrong? Folly Mox (talk) 17:08, 9 January 2024 (UTC)
You are either doing it wrong or I don't understand what you mean by that question. {{citation}} has supported |chapter= and its aliases since forever ago:
{{citation |chapter=Chapter |title=Title}}
"Chapter", Title
—Trappist the monk (talk) 17:19, 9 January 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Help_talk:Citation_Style_1/Archive_92&oldid=1227567867"