Help talk:Citation Style 1/Archive 93

This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

At least one editor seems to be interpreting Template:Cite news#COinS to mean that named HTML entities like   are unwanted, but that numeric HTML entities like   are OK in fields that contribute to COinS metadata...I think because there are no numeric entities listed as examples? I was planning to add some numeric examples unless I'm missing something? -- Beland (talk) 22:23, 9 January 2024 (UTC)

That's a funny one.  — SMcCandlish ☏ ¢ 😼  22:33, 10 January 2024 (UTC)

Added proposed example. -- Beland (talk) 22:32, 11 January 2024 (UTC)

Hi, I want to add {{cite journal}} with url https://periodika.lndb.lv/periodika2-viewer/?lang=en#panel:pp%7Cissue:45046%7Carticle:DIVL1125 that has pipe characters in it. The template thinks that "issue:45046|article:DIVL1125" are random unrecognized text and not part of the url. What's the workaround here? Thanks, Renata•3 01:43, 13 January 2024 (UTC)

Actually, nevermind, just resolved my issue. Saving the url replaced pipes with %7C and that works. Renata•3 01:45, 13 January 2024 (UTC)

That's the best way %7C. Thank you. Some editors replace pipe in URLs with {{!}} but this monstrosity mixes percent-encoding and wiki-encoding in the same URL, which violates RFC 3986 and makes every tool and bot writer reach for garlic and crosses. MediaWiki software allows for the mixing of encoding types within a URL is an example of an Internet worst practice. -- GreenC 02:17, 13 January 2024 (UTC)

This edit request to Template:Cite journal/doc has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change Cite journal/doc to^[1] Mary Foundation at TheHowMan (talk) 02:45, 15 January 2024 (UTC)CatholiCity.com TheHowMan (talk) 02:45, 15 January 2024 (UTC)

 Not done: why? --AntiDionysius (talk) 02:47, 15 January 2024 (UTC)

Why in the world is the use of   being recommended in Template:Citation Style documentation/doc#Full vertical style? This results in those entities being visible in the resulting tables, like this (from Template:Cite magazine/doc — of course, I've omitted most of the rows):

{{cite magazine
| last1                 = 
| first1                = 
| author-link1          = 
| last2                 = 
| first2                = 
}}

 
 
 last1
 
 last1
 last2

 
 
 
 
 
 

That looks really, really bad.

This is how it should look:

{{cite magazine
| last1                 = 
| first1                = 
| author-link1          = 
| last2                 = 
| first2                = 
}}

 
 
last1
 
last1
last2

And that can be accomplished by simply using normal space characters in place of the  s.

I assume something changed recently that caused the entities to become visible, when they weren't before. Can we please change this on all the relevant doc pages? (I can do some of that.) - dcljr (talk) 19:20, 16 January 2024 (UTC)

@Dcljr: They were broken in this edit[1] and fixed here.[2] Thanks for catching it. The table used by the documentation on {{cite book}} seems like a better way to handle this. After checking the other documentation pages, many of them that don't have this formatting error, could use other types of improvement. For example, the {{cite encyclopedia}} documentation has had only minor changes (to update parameter names) since 2006.[3] Less commonly used templates just omit a full list of parameters. Rjjⁱⁱⁱ (talk) 22:45, 16 January 2024 (UTC)

Note that the columns no longer line up properly after your edit to Template:Cite magazine/doc (e.g., it's not clear that "last1" is a prerequisite for "first1"). I'd say a totally different format is called for (like that of Template:Cite book/doc, as you pointed out). The approach that we are discussing seems easily broken (as demonstrated here) and unnecessarily difficult to maintain. - dcljr (talk) 23:38, 16 January 2024 (UTC)

@Dcljr: I switched the parameters back to the old format also now. {{cite news}} was the only other template with this issue on the documentation. Rjjⁱⁱⁱ (talk) 00:19, 17 January 2024 (UTC)

OK, obviously we are both trying to edit the page at the same time. I'm stopping. - dcljr (talk) 00:24, 17 January 2024 (UTC)

@Dcljr: I'm done now. Do the columns look lined up? Rjjⁱⁱⁱ (talk) 00:26, 17 January 2024 (UTC)

Looks like it. And verified that both columns have the same number of rows. I guess it's OK now, since there shouldn't be any need for syntax highlighting in the middle column. But as I pointed out, just replacing the  s by regular spaces also worked. Like I said, this is a terrible format to use on such a large table. I plan to convert it to the other format "soon", unless I can be persuaded not to. - dcljr (talk) 00:36, 17 January 2024 (UTC)

Oh… I just noticed you left it without syntax highlighting in either (/any) column. Whatever. - dcljr (talk) 00:40, 17 January 2024 (UTC)

Yes, that's how it was done before.[4] I don't have objections to a different format. Good luck! Rjjⁱⁱⁱ (talk) 00:42, 17 January 2024 (UTC)

As a followup to the previous section (#Visible nbsp entities), I recommend removing the instructions about the "Three-columns format" entirely from Template:Citation Style documentation#Full vertical style. Even for short tables, if any row in either the "Prerequisites" or "Brief instructions" column is too long, the rows will no longer line up due to line-wrapping. (See this in the wild. Here's a more extreme example, with wrapping in every column.) And for long tables, it's a nightmare to maintain. (And, as seen above, the recommendation to use   in blank rows fails when using <syntaxhighlight>, which some people will be tempted to do, instead of <pre> or <code><nowiki>.) For so many reasons, this seems like a terrible way of doing the "Full parameter set in vertical format" table. Can I get consensus to remove it? - dcljr (talk) 02:01, 17 January 2024 (UTC)

This edit request to Module:Citation/CS1/Configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Remove the following line, Reuters is a perfectly legitimate news agency and hence a valid corporate author, not a "generic name":

{['en'] = {'reuters', true}, ['local'] = nil}, Coco (talk) 14:53, 17 January 2024 (UTC)

@Cocô53: Since Reuters is a news agency, we should use |agency=Reuters instead of |author=Reuters or |last=Reuters. GoingBatty (talk) 20:11, 17 January 2024 (UTC)

@GoingBatty: Ok, my bad, I think I thought |agency= was just an allias for |publisher= due to this being positioned in the same place, not where |author= is. On the French language Wikipedia there is a parameter "institutional author" that appears first, and I was looking to use "cite web" to produce a similar effect. --Coco (talk) 23:18, 17 January 2024 (UTC)

Is there a reason why the {{cite book}} template does not have a trans-series parameter? I noticed it for this book, cited in Lokrume helmet fragment and other articles; the name of the series is in Norwegian, but there is no way to translate it.

• Grieg, Sigurd (1947). Gjermundbufunnet: En høvdingegrav fra 900-årene fra Ringerike [The Gjermundbu Find: A Chieftain Grave from the 900s from Ringerike]. Norske Oldfunn (in Norwegian). Vol. VIII. Oslo: Bergen. OCLC 984069139.

--Usernameunique (talk) 19:01, 17 January 2024 (UTC)

Hello. Can I ask you, please, to move all the limits to the module:Citation/CS1/Configuration wikidata page, to prevent bumping the numbers again and again for every local wiki version? There is definitely some property that can be used for this. IKhitron (talk) 15:08, 18 January 2024 (UTC)

That might be a good idea. There is definitely some property that can be used for this. If you know what those properties are (if they exist), please add them or tell us what they are. If those properties do not exist, I don't hold any hope for them ever existing. The last time I tried suggesting new properties over there at wikidata (on an unrelated topic), I was shot down in flames so after that scorching I'm rather fire-shy.

—Trappist the monk (talk) 15:17, 18 January 2024 (UTC)

I don't know Wikidata well enough, I think somebody that do should be asked about this. I hope there are. But even if there are not, you can always use the Commons data tables. It's more work to create the system, but better then nothing, FMO. IKhitron (talk) 15:22, 18 January 2024 (UTC)

Have you got a link to documentation about Commons data tables? Avoiding the politics of wikidata seems like a win to me if commons data tables will work.

—Trappist the monk (talk) 15:28, 18 January 2024 (UTC)

mw:Help:Tabular Data. But I think better to check if these Wikidata properties already exist, before worring about politics if they don't. IKhitron (talk) 15:33, 18 January 2024 (UTC)

I have created c:Data:Sandbox/CS1/Identifier limits.tab which is a simple tabular-data page that holds the limit values for the seven identifiers that use limits. I have also hacked Module:Citation/CS1/Configuration/sandbox to use the limit values from that tabular data page. The current limit for PMC is 10900000:

A possible downside to this mechanism (and also to wikidata) is that the tabular data are available for anyone to edit so vandalism and incompetence (tabular data is in JSON format – same as TemplateData – so is inherently fragile). A simple experiment indicates that the omission of a comma (and perhaps one of the necessary brackets – [, ], {, or }) is detected and while broken, the file cannot be saved.

—Trappist the monk (talk) 20:51, 18 January 2024 (UTC)

Well, it's your choice. But there is always a possibility to protect the file, and for the special cases to put into the module some extremally large default values which will play if the file is temporarly broken. IKhitron (talk) 20:59, 18 January 2024 (UTC)

Find a wikidata property suitable for identifier limit values that is allowable by those who maintain wikidata, and we can certainly experiment with that.

I think that I would choose to go the other way: an extremely small default value (perhaps 0) so that it becomes immediately obvious that something has gone terribly wrong with the tabular data. With a very small value all cs1|2 templates using that broken identifier limit value will show an error message whereas with an extremely large value, there will be no indication of a problem; that is not helpful.

—Trappist the monk (talk) 23:19, 18 January 2024 (UTC)

Again, I don't understand enough in Wikidata, but I'll ask some people.
About the default value, it's your choice, once more. I suggested a large number from exactly the same reason, error message, to avoid millions of articles in tracking categories. IKhitron (talk) 23:23, 18 January 2024 (UTC)

The identifier tests that use the limit values from the tabular data are all, more-or-less, variants of the form: if identifier_value > id_limit_value then error end. If the default-because-broken id_limit_value is a very large number, there will be no error message because id_limit_value will always be greater than identifier_value. When that is the case, no one will know that a problem exists. That no one knows that a problem exists is, to me, a bigger problem than a lot of articles in tracking categories.

—Trappist the monk (talk) 23:58, 18 January 2024 (UTC)

Well, I've asked, and get three names to talk about this. One of them is you, so I can't use it. @Pigsonthewing and @Wittylama, is there a chance you know some Wikidata properties that fit to this cause? IKhitron (talk) 00:27, 19 January 2024 (UTC)

@Mike Peel? Wittylama 01:50, 20 January 2024 (UTC)

Could you please consider expanding Category:CS1 errors: extra text: edition to capture values where "edition" is in a foreign language? For example this search finds 27 instances of "baskı", the Turkish word for "edition". Thanks! GoingBatty (talk) 23:07, 19 January 2024 (UTC)

Cite journal does not properly handle hyphenated first names when using |name-list-style=vanc. For example:

• Tsai HM (February 2006). "Current Concepts in Thrombotic Thrombocytopenic Purpura". Annual Review of Medicine. 57: 419–436. doi:10.1146/annurev.med.57.061804.084505. PMC 2426955. PMID 16409158.
  • The author's name is Han-Mou Tsai with a hyphenated first name, but when style is turned to vanc, his name is displayed as "Tsai H", treating his first name as one name. In published literature citing him, they usually cite him as "Tsai HM" or occasionally "Tsai H-M", but not "Tsai H".

The template's code should be updated to cite authors with hyphenated first names more accurately. BhamBoi (talk) 07:16, 28 December 2023 (UTC)

Fixed in sandbox. Also removed allowance for a comma separator between given name(s) and generation suffix.

—Trappist the monk (talk) 15:06, 28 December 2023 (UTC)

Will this be going live? BhamBoi (talk) 00:34, 15 January 2024 (UTC)

Additionally, assuming the above changes go live (@Trappist the monk), would there be added support for 3 letter first names in Vancouver style? e.g. 'das Neves, Paulo Cesar Pereira' would become 'das Neves PCP' instead of 'das Neves PC' BhamBoi (talk) 08:17, 20 January 2024 (UTC)

The rule, as stated at Citing Medicine: The NLM Style Guide for Authors, Editors, and Publishers is:

Convert given (first) names and middle names to initials, for a maximum of two initials following each surname

When that rule changes, so shall cs1|2. Until then, two initials.

—Trappist the monk (talk) 15:16, 20 January 2024 (UTC)

Okay. I can live with that. But can the changes with the hyphenated first names get implemented? Thanks for all you do :) BhamBoi (talk) 17:25, 20 January 2024 (UTC)

Could you please consider expanding Category:CS1 errors: extra text: volume to capture values that include the word "issue" or "Issue"? For example this search finds 53 instances of "issue", which doesn't include the 12 I fixed manually. Thanks! GoingBatty (talk) 01:52, 20 January 2024 (UTC)

Help talk:Citation Style 1/Archive 92 § Extra text in |volume= and |issue=

—Trappist the monk (talk) 01:58, 20 January 2024 (UTC)

@Trappist the monk: Thank you for the reminder about that conversation. I checked a few of the results, and they don't seem to be caught in either error category live or in the sandbox. What am I missing?

GoingBatty (talk) 02:52, 20 January 2024 (UTC)

One more, just to confirm it's an issue (pun intended) with both "Issue" and "issue":

GoingBatty (talk) 02:56, 20 January 2024 (UTC)

The 'issue' tests expect that 'issue' and its variants will be the first element found in a parameter value. I don't recall why the tests are constrained like that. Anyone?

All of your examples begin with digits so we might write additional patterns:

^%d+[,;:%-]?%s*[Ii]ssues?

^%d+[,;:%-]?%s*[Nn]umbers?

etc

But, such patterns would catch stuff like |volume=1: Number of Inhabitants which we should not catch. Given that, I suspect that what you are asking is better suited to specialized searches.

—Trappist the monk (talk) 15:06, 20 January 2024 (UTC)

I've seen some removals of this at articles lately. Are we certain this is really redundant? There's a potential difference to me here between "someone has checked this and we know that it is dead" and "no one has checked this and the parameter is missing". It seems to me that removing it could just lead to unnecessary editorial time-waste checking to see if the non-archive original URL is actually live or not. If we're sure it's not needed, I'm okay with that; I'm in favor of reducing redundancy. (Like why oh why do people keep adding |language=en when that's the site-wide default when no other language has been explicitly specified? And doubleplus why do people keep doing |langauge=en-GB, etc., when the exact dialect of the source is irrelevant? No one competent to read American English is going to need a translator to read British English.)  — SMcCandlish ☏ ¢ 😼  14:07, 31 October 2023 (UTC)

Re the language parameter, I doubt this is people adding it, more not removing it. The citation tool adds the parameter automatically if it finds the relevant information on the source page. Nthep (talk) 14:51, 31 October 2023 (UTC)

Hmm. So, how to get that to stop happening when (on this site) the value returned in en or en-*? It's annoying, and resulting in an unbelievable amount of pointless code bloat.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

Having |language= set helps with translation efforts. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:18, 31 October 2023 (UTC)

Any translator taking material from en.wikipedia.org already knows that the default language is en, and 99%+ of our cites to en sources do not have this parameter, so it is not helping with translation efforts. Even if it was, somehow, some way, it is not worth the amount of code bloat in our live articles.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

It's very little code bloat, especially as the reader doesn't even see it. Also a lot of non-technical editors translate articles and rely on automatic trasnlation of cites. The mass removal has been previously discussed on one of the village pump pages, and gained no traction. I was initially for removing it, but came to see the other sides point. It's 12 characters, it hurts no-one and helps some. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:02, 31 October 2023 (UTC)

No readers ever see any code bloat, because it's in the code, by definition. It's an editing and maintenance issue, not an end-user readability matter. It's 12 (often 15) characters over and over and over again on page after page after page. Not trivial. Mass removal of anything generally gets opposed on "I don't want my watchlist going nuts" grounds, especially when the change does not affect the reader's view. So that's not a principled position against deprecating this usage and getting tools to stop automatically doing it. If there's an actual use case for this, I have yet to see it, and I've been here 17 years. I guess I will go see if I can find some arguments for it that I missed, since you suggest there are some, but these vague hints are not promising. If the user already knows by default that the material will be English (and besides, the entire page already has lang="en" for its entire content except were explicitly overridden), there doesn't seem to be an auto-translation-tools reason for this.  — SMcCandlish ☏ ¢ 😼  17:22, 31 October 2023 (UTC)

That's how the auto-translation tools work and usually they are translating the cite once they have reached the target wiki, so no lang="en" is not set. You've missed that {{Ouvrage}} is a redirect to {{Cite book/French}} for instance, and what AnomieBOT does when it's used. So there is a explicit reason to have it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 31 October 2023 (UTC)

Can you explain what you mean in more detail? If the tools are translating some other wiki's content, then that wiki will be providing its own lang information already. I don't see what the {{Ouvrage}} redirect has to do with anything, or {{Cite book/French}} for that matter, since if it's translating a template imported with French-language parameters from fr.wikipedia, that template will already either be for a French source (by default) or come with a |language=en (or I suppose |langue=en) if it's an English-language source being cited, and not need a |language=en parameter newly added, plus will get substituted out by a bot anyway and no longer need that parameter after the work is done. Am I missing something still? The fact that there are special and short-term use cases for |language=en doesn't seem to translate (pun intended) into a stick-them-in-every-English-citation-redundantly rationale.  — SMcCandlish ☏ ¢ 😼  18:06, 31 October 2023 (UTC)

Just because {{Ouvrage}} was imported from fr.wiki does not mean that the source is written in French – likely it is, but there is no guarantee. fr.wiki doesn't use cs1|2 but they do have |langue=. At fr.wiki, when |langue=fr, the language output is suppressed; that's where we got the idea to suppress the output here when |language=en.

—Trappist the monk (talk) 18:34, 31 October 2023 (UTC)

1. An editor translates the article text.
2. The editor directly copies the cites without any translation.
3. Anomiebot substitutes the cites using Cite book/French as direction of how to correctly rename the fields.

All this happens on enwiki, so unless the frwiki cites have |language=fr set the cites on enwiki don't have it either. All of this makes it easier for editors to translate articles without having learn the technical details of how the templates work.

It is a real and specific reason to include |language=en. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:58, 31 October 2023 (UTC)

"makes it easier for editors to translate articles" is an almost entirely theoretical idea, since nearly none of our citations to English-language sources have |language=en. There is surely a better way to do this than dumping enormous amounts of redundant code into our articles. The fact "this could work to make translation easier" doesn't make this the best, or even a reasonable, idea in furtherance of that goal. (If I need to move my car over by one foot, I could do it by hitting it with sledgehammer and over and over on one side, moving it a milimeter at a time, but this would not be a good idea.) Fr.wikipedia should be presuming by default that a copy-pasted citation off of en.wikipedia that they are using a local tool to translate into an equivalent French cite template is by default an English-language source. There is no reasonable other assumption to make. I'm not convinced in any way that whatever need is being flagged here can only, or even best, or even practically, be solved by jamming in literally millions of |language=en instances. I think we are more clever than this and can build better, cleaner-running tools. Same with "unless the frwiki cites have |language=fr set the cites on enwiki don't have it either"; if our template-translation tool knows the template is from fr.wikipedia (and it would have to, to properly parse the parameters) then we already know that the default thing to do, absent something like a |langue=zh in their template, is to add |language=fr in our version.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

As I said earlier I was convinced of it in another discussion, because people are actively using it this way so no it's not theoretical in anyway. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:26, 1 November 2023 (UTC)

This is more vague "I saw something somewhere once" hearsay. We need specifics, and an examination of whether their alleged need for this can be met some other way that doesn't entail adding millions of blobs of otherwise unneeded code all over the 'pedia.  — SMcCandlish ☏ ¢ 😼  18:09, 1 November 2023 (UTC)

I'm not going to go and dig around every VP archive to find the discussion, and it's obvious even that would not change your mind so I'll drop it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:13, 1 November 2023 (UTC)

My mind actually frequently changes, especially on matters like this, in response to evidence that can't be easily dispelled (like some of the translation-related arguments made so far can be, but there may be stronger ones). I don't think it's unreasonable to respond with "show me" when someone says "I've seen the proof".  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

The problem is not that no people ever could be using it this way. The problem is that (a) only vanishingly few current citations include this, so it can't be relied on, (b) that most citations are in English is obviously implicit here, and describing that explicitly adds a lot of boilerplate noise to the template, (c) the harm of Wikipedians translating English articles to their own language and accidentally not tagging all of the citations as being in English is temporary and pretty trivial, (d) large-scale automated edits adding it to existing citations are a big distraction not justified by the trivial benefit. This problem would be much better addressed by fixing whatever automatic translation tool people are using. –jacobolus (t) 18:16, 1 November 2023 (UTC)

And |language=en is 12 characters that hurts no-one , so what. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:15, 1 November 2023 (UTC)

The citation templates are already a lot of noisy boilerplate, even in the best case, and a magnet for relatively useless redundant metadata. The longer and more annoying filling out the templates gets, and the more often bot-like editors come and pointlessly twiddle the parameters for little or no benefit to readers, the more I'm tempted to just use plain wikitext for citations, optionally with {{wikicite}}. Every new hoop the templates make human editors jump through is another step in the wrong direction. –jacobolus (t) 22:50, 1 November 2023 (UTC)

No new hoops are being added as I said no-one has suggested mass adding it, or the need for editors to add this parameter when setting up cites, or for any editors to go adding this parameter to already existing cites. Many cites that are created automatically using lookups include this parameter, this is not something that is controlled by the editors maintaining these templates. You have the whole discussion back to front. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:59, 1 November 2023 (UTC)

I thought the problem was with people making edits adding language=en to existing citations? If not, what's the complaint? –jacobolus (t) 23:04, 1 November 2023 (UTC)

The discussion is that it should be removed from cites that already have it, which I feel is a waste of time and could negatively impact some editors is niche situations. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:10, 1 November 2023 (UTC)

If someone wants to incidentally remove language=en in a citation or two as part of reformatting them, fine. Automatic removal of language=en on a wide scale seems like a big waste of attention. –jacobolus (t) 23:36, 1 November 2023 (UTC)

(edit conflict)

|language=en has nothing to do with the html attribute lang="en". The |language= parameter is there so that readers can know the language of the cited source; see the template doc. cs1|2 suppresses rendering of the source language when the source language is the same as the local wiki's language. If a cs1|2 template is never, ever, going to be copied to another language wikipedia, then |language=en is obviously superfluous. If the cs1|2 template may be copied to another language wikipedia, then |language=en renders the source's language in the local language without the copying editor having to do anything: at sq.wiki, for example, |language=en renders as '(në anglisht)'. Leaving |language=en aids editors who copy en.wiki articles to their home wiki and does no harm to editors here. Translation is aided by editors here using the ISO 639 language tag instead of the language name because MediaWiki will provide the name in the local language without the editor there having to translate 'English' to the local language or to the ISO 639 tag.

—Trappist the monk (talk) 18:25, 31 October 2023 (UTC)

If our only or primary rationale for injecting |language=en eventually millions of times into our content is to save someone the trouble at another wiki of adding their local equivalent of |language=en to citations they copied from us, then my opposition to this idea is now more solidified than it was to begin with, especially since a template translation tool can be configured to just add that parameter by default any time it is working with a template that it recognizes as having come from en.wikipedia and which doesn't say something like |language=ja (and the tool would have to be able to do that recognition or it would not be able to convert the highly particular template parameters to the local version in the first place).  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

I entirely agree. Please everyone let's not start havings bots or humans-pretending-to-be-bots add language=en to every citation. What a massive waste of time and attention. And please don't start randomly adding language=en to a hodgepodge subset of citations either. This is an unnecessary and unhelpful thing to include. –jacobolus (t) 06:43, 1 November 2023 (UTC)

No-one is suggesting any such thing, this discussion is actually about the opposite - the exclusion of |language=en not adding it. Many tools will automatically add this when editors use auto-creation, if you disagree with that this is the wrong talk page as those tools are not maintained here. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:23, 1 November 2023 (UTC)

The direct implication of al these "it's so useful for translating" claims (which have so far been unevidenced or easily dispelled, but maybe there is a better one yet to be made) is that eventually they will be imposed everywhere. It's a natural consequence of the argument that they're useful. They're only useful if they're imposed consistently. So raising this concern is in no way out-of-bounds.  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

They have not, and as above please don't try to restart this. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:30, 1 November 2023 (UTC)

"They have not" what? That has no clear referent, either as to what comes after "not" or what/who "they" is.  — SMcCandlish ☏ ¢ 😼  06:44, 2 November 2023 (UTC)

I know that I also have seen comments here and there also that the use for translation happens. Take it on faith that we're not spouting complete bullshit. :) You can still make your other points ad arguendum regardless.

As for mass-addition of |language=en, that is definitely a strawman. The only system that does anything remotely like that is Citoid (and other systems that use Citoid's output these days) when a website puts a language into its HTML. And like all such citations, I clean the ones that have totally garbage output that often get caught in our category dragnets and allow someone else to state a preference on whether |language=en actually should exist in the article or not. Following the principles of WP:CITEVAR even if this case is one ultimately of wikitext formatting (where we have already established the requirements of CITEVAR don't apply besides to the distinction between using CS1/2 and a hand-input style) and annoyance with what some see as clutter to-be-removed rather than clutter to tolerate for the health of the movement rather than our specific wiki. Izno (talk) 21:06, 4 November 2023 (UTC)

Yes, |url-status=dead in the presence of |url= and |archive-url= is meaningless. When given |archive-url= with an assigned value, Module:Citation/CS1 assumes that |url= is dead. It has been ever thus:

I don't know where that extra archive.org url is coming from

{{cite book/old}} does not know about |url-status=. Rewriting the example template to use |deadurl=yes returns the exact same result

{{cite book/old|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|deadurl=yes}}

Title. Archived from the original on 2023-10-21. https://archive.org. 

Rewriting the example template to use |url-status=dead returns the exact same result with the live template:

{{cite book|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|url-status=dead}}

Title. Archived from the original on 2023-10-21.

|url-status=dead is not a substitute for {{dead link}}. |url-status=dead is never needed and is always redundant. Perhaps the dead keyword should be deprecated and support for it withdrawn.

—Trappist the monk (talk) 15:11, 31 October 2023 (UTC)

This would definitely help with editors misusing it to mark dead links. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:19, 31 October 2023 (UTC)

Okay, if it's really useless, and it's causing confusion with {{dead link}}, then I'm all for the deprecation, will stop using this parameter, and will remove it (and the old |deadurl=yes) when doing cite cleanup. Update: Now not sure sure of that, given the disputation below.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC); revised: 18:16, 1 November 2023 (UTC)

The behavior described here, of always treating urls that have an archive-url as being dead, is fucked up. In most cases when there is a live url, we want to send readers to the live url, because in most cases updates to the content are helpful to readers. When Internet Archive Bot or whoever adds an archive-url as a prophylactic measure rather than because the url has gone dead, that should not suddenly make that version of the url be the only one that readers ever see going forward. —David Eppstein (talk) 16:02, 31 October 2023 (UTC)

If |url= is live when InternetArchiveBot adds |archive-url= to a cs1|2 template, it should set |url-status=live. If IABot is not doing that, you should take up the issue with its maintainer either at User talk:InternetArchiveBot or at User talk:Cyberpower678.

—Trappist the monk (talk) 16:24, 31 October 2023 (UTC)

I strongly agree with @David Eppstein. @Trappist the monk removing these parameters en masse without community consensus is disruptive. Please immediately desist until you have broad support. –jacobolus (t) 22:48, 31 October 2023 (UTC)

Here's what I said at user talk:Trappist the monk: Including "url-status=dead" is much more explicit communication to human editors than just leaving url-status out entirely. It's important because the internet archive's bot (and various human editors) keep adding archive URLs to still-living pages, so the mere presence of an archive URL is not sufficient to communicate that the original page is dead, but instead what it communicates is "whoever added the archive URL was too lazy to check", which then wastes follow-up effort by other editors manually checking all of these.

conveys no meaningful information – this is not true. url-status=dead clearly communicates that the link is dead. The complete absence of such a parameter does not communicate the same thing. You should not be removing these en masse without community consensus. –jacobolus (t) 22:50, 31 October 2023 (UTC)

Agreed - the parameter is useful. There are several news sites where current live url requires subscription for full text access, but the Internet Archived version from the first day the article was live allows the user to access the full text; when I use this cludge, I do typically include some note to the reader indicating this in the citation. Regards. User:Ceyockey (talk to me) 00:28, 1 November 2023 (UTC)

Well, if you're already manually including a note to this effect, using the parameter to also signify this in a really subtle way would seem to be redundant. For most use cases, we don't have a rationale to completely suppress the link to the original URL anyway, since a source that requires a subscription is not forbidden. I think the proper thing to do is this: {{cite news |title=Maps: Tracking the Attacks in Israel and Gaza |date=October 31, 2023 |work=The New York Times |url= https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |url-access=subscription |url-status=live |archive-url= https://web.archive.org/web/20231101004026/https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |archive-date=November 1, 2023 |access-date=November 1, 2023}} I just tested in a sandbox, and this has the original URL available and flagged with the subscription icon, and the archive-url available with no such flag. People with NYT subscriptions can use the former, everyone else the latter, and if a user clicks first on the former but has no subscription and just didn't pay attention to the icon, and has to backtrack and click the IA link instead, the sky has not fallen down. Especially if you're also adding a note along the lines of "Full text available free at the archive link." PS: This cite type definitely works for NYT, and Washington Post (e.g. [5]), but I don't know if IA's archival stuff manages to defeat other paywalls. Sometimes there might not be a useful archive-url with the full text, and we might be stuck with just |url=...|url-access=subscription. So it goes.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

Adding url-status=live is obviously helpful for a live link. But adding url-status=dead is also a helpful signal for a dead link, because it is explicit rather than implicit. A human reader of either of those can immediately tell what the person who added the parameter meant, instead of being forced to guess. –jacobolus (t) 06:46, 1 November 2023 (UTC)

Thanks for the advice. User:Ceyockey (talk to me) 00:01, 4 November 2023 (UTC)

Are we certain this claim about Internet Archive Bot is correct? Does someone have a recent diff of this or any other bot adding |archive-url= without |url-status=live when the original page is in fact live? If it is happening, wouldn't the solution be to fix the bot rather than add redundant |url-status=dead to zillions of citations? Is occasional human error sufficient reason to do it? Especially when the whole point of the archive-URL is that it is working copy of the source in question, so no reader is harmed by going to that version instead of the original anyway? I'm skeptical that we should be tolerant of longwinded code bloat on a massive scale as the solution to an alleged bot problem that should be easily fixable, and a human-error problem that is like unto an innumerable number of other trivial human errors we deal with without going to such extremes. I would think also that whether or not |access-date= is older than |archive-date= is already the functional system we have for determining whether the original URL has been checked for live status when adding the archive-url, or whether someone or something just tacked one of the latter on in drive-by fashion without checking whether the status is live.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

whether or not |access-date= is older than |archive-date= is already the functional system no this is by no means adequate. It's based on a chain of dubious inferences which are regularly violated. –jacobolus (t) 06:47, 1 November 2023 (UTC)

I spot checked the first 30 or so diffs at Special:Contributions/InternetArchiveBot. I found one instance of IABot adding |url-status=live(Special:Diff/1182963903) and one instance of the bot adding |url-status=bot: unknown (Special:Diff/1182966277). To every other cs1|2 template touched by the bot, it added the superfluous |url-status=dead.

—Trappist the monk (talk) 13:38, 1 November 2023 (UTC)

The bot is generally using these parameters in a reasonable way. Having the bot be explicit about whether the URL is live or dead is a good thing.

Personally I'd prefer if people (or bots) never prophylactically added archive links to still-living pages except in special circumstances with some human intention involved (e.g. the "living" page is paywalled). –jacobolus (t) 14:04, 1 November 2023 (UTC)

The purpose of |url-status= is to tell Module:Citation/CS1 what to do when presented with both |url= and |archive-url=. In the absence of |url-status=, Module:Citation/CS1 defaults to linking |title= with |archive-url=; this is the module's default case. Setting |url-status=dead does not instruct the module to do anything different from its default (thus my conveys no meaningful information comment). The addition of |url-status=dead is therefor pointless, redundant, code bloat, clutter, pick your favorite term. Parameters that accomplish nothing have no value so should be removed.

—Trappist the monk (talk) 13:38, 1 November 2023 (UTC)

The purpose of url-status is to communicate the status of the URL, both to the citation rendering template, and also to human editors. –jacobolus (t) 14:05, 1 November 2023 (UTC)

The purpose of |url-status= is to control the selection of the live URL or the archive URL, as the documentation has always shown. It does not and has never been for the url-status of the source, does that make it confusing named - yes - should it be used to show the status of the URL - no that's what {{dead links}} is for as that template actually shows the link is dead to the reader (url-status=dead give no display output to the reader). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:20, 1 November 2023 (UTC)

The way you tell *readers* that the link is dead is by switching the order of the links and making the archive link primary. The way you tell markup-reading *editors* that the link is dead is with the "url-status" parameter. Leaving this parameter out entirely is not explicit enough to clearly communicate the status of the URL. When the parameter is left out, human editors will waste their time double checking all of the links, because the status is not communicated clearly and unambiguously. –jacobolus (t) 22:52, 1 November 2023 (UTC)

To be more concrete/explicit, it is confusing to have:

No archive URL → url-status is implicitly alive

Archive URL → url-status is implicitly dead

This is okay as a fallback interpretation, but it is much better still to have an explicit url-status included whenever there is an archive URL, because it is then entirely clear what was intended and what the most-recently-checked URL status is. An editor who checks the link can just change dead ↔ live as needed. –jacobolus (t) 23:01, 1 November 2023 (UTC)

I think we're just saying the same thing slightly differently and from different directions. I agree that url-status is used to select whether the URL or archive URL is used.

The problem is that editors use it when no archive URL is present. So the URL is dead, no archive link is present, and they set |url-status=dead rather than use {{dead link}}. It's that scenario I'm saying is wrong. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:09, 1 November 2023 (UTC)

The problem is that editors use it when no archive URL is present – this is different than the problem I am complaining about, which is semi-automated edits which do nothing but remove url-status=dead from links that have an archive link. –jacobolus (t) 23:39, 1 November 2023 (UTC)

Yeah I thought we were talking at cross purposes. I'm against editors mass removing these, it's just a pain that it gets misused a lot. Editors also incorrectly add |url-status=live to cites with no archive url, which does generally get removed. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 01:56, 2 November 2023 (UTC)

Though it might not be a bad idea to allow url-status=dead even without an archive link, and format the output the same as {{dead link}} in that case. –jacobolus (t) 23:42, 1 November 2023 (UTC)

Which guidance does it violate, when a link is dead, an archive exists, and no alternative url is found hosting the information, to set the |url=(archive page)? I'm pretty certain this is against some policy or another, but I'm not sure which one, and it seems like a natural shortcut when citing deadlinked sources. Folly Mox (talk) 00:41, 2 November 2023 (UTC)

I concur with jacobolus. When there is no url-status there is a higher probability a mistake was made. The explicit url-status provides a greater degree of assurance what the last editor intended. It's not intuitive that a missing url-status is the same as dead, more like an expert editor's shortcut. -- GreenC 23:11, 1 November 2023 (UTC)

I'd be happy with renaming the field |archive-req= with yes/no/usurped/deviated being the answers, but at this point that would probably break to many things. My point was that it's not a field to mark the URL status, it's for showing which URL to use. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:17, 1 November 2023 (UTC)

Yeah, that would lead to massive breakage. And it's not clear what it even means ("archive-req"?).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

Well, someone's still removing |url-status=dead from random articles, but I don't get the sense that there's actually a consensus in favor of the idea. I like the notion of removing any parameter that is actually redundant, but in fairness I'm not certain this is seen to be reundant, regardless what the original idea for implementing the parameter was. But that kind of concern in and of itself has not always won the day (e.g., I and others were basically just overridden on the use of |access-date= as an indicator of when someone last actually looked at the source, of any type, to see whether it agreed with the content it was cited for, and it has been disabled for anything without |url= because the original idea of the parameter was supposedly just indicating when the URL was checked to be valid/loading at all). People can have different points of view about these things. I am fairly certain that MEATBOT-style removal of |url-status=dead should probably not be happening while this discussion is unsettled, though. (Just as I have stopped normalizing ISBNs to hyphenless form since there's a discussion open at VPPOL about what should be done).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

I continue to remove the parameter when it appears in an article of interest, though it's not a category I focus on. I do so for the same reasons as presented by Trappist, and for the same rationale for the parameter's creation. Izno (talk) 21:13, 4 November 2023 (UTC)

To some degree, I find it ironic and/or hypocritical that in the very same section we have people arguing that |language=en is cruft and unnecessary and to be removed despite at least one valid use case, and |url-status=dead (for dead URLs) is not. Izno (talk) 21:15, 4 November 2023 (UTC)

In my opinion, language=en is by far the majority case, and very obviously implicit for every citation and not at all a point of confusion. Also even for non-English links, leaving out an explicit mention of which language the citation is in is a kind of trivial oversight of minimal harm to readers (because for example the title is usually written in that language; someone seeing a source with title in German or Latin is not going to be excessively surprised that they don't get an English page when they click). There really isn't any need to be explicit that every ordinary citation to a source with a title and other metadata written in English points to an English language source. So including that parameter redundantly is pointless cruft. I don't mind if someone copy/pastes a citation from another language wiki and happens to leave language=en; in that instance its presence isn't doing any harm and doesn't need to be immediately cleaned up or anything. But I definitely don't want us to have a bot crusade inserting language=en to every citation site-wide, which would be extremely obnoxious to say the least.

By contrast, citations to web pages which also include an archive link are not inherently obviously aimed at a dead link. An archive link might also be included because e.g. the original source has since been put behind a paywall, or because the IABot or some editor trying to be helpful has obnoxiously added a "prophylactic" archive link to a still living page. Interpreting the presence of an archive link without any explicit mention of the URL status to mean the archive link should be primary is an okay default fallback (we have to assume something in this case, and neither choice is a priori obviously correct). But having an explicit parameter is better, because it communicates clearly to human editors examining the source. This parameter is not pointless, even if its presence does not change the rendered output. Having a bot or meat bot remove url-status=dead at large scale based on personal preference of one editor is also super obnoxious. –jacobolus (t) 23:07, 4 November 2023 (UTC)

But having an explicit parameter is better, because it communicates clearly to human editors examining the source. Agreed and that parameter is |url-status=live; that parameter and value not present? Assume dead.

—Trappist the monk (talk) 23:24, 4 November 2023 (UTC)

You can't say exactly the opposite of my point and then summarize that as "agreed". Come on... –jacobolus (t) 23:32, 4 November 2023 (UTC)

Apologies for necroing this thread, and so deep in the indents no less, but I noticed that User:Citation bot is removing |url-status=live from live URLs, and I immediately thought of the exchange just above. Do we, ultimately, have any idea what the default / unset value for this parameter indicates? Folly Mox (talk) 09:56, 3 December 2023 (UTC)

It's not "ironic and/or hypocritical" to oppose inclusion of one parameter and support keeping another for completely unrelated reasons. The "valid use case" for |language=en has been quite thoroughly refuted by multiple editors, and when the other side is asked for a better use case (and they keep saying they've seen one), they wave their hands and walk away. When it comes to |url-status=dead, a very broad, works-for-everyone use case has been presented, and the response so far as been an argument that the original purpose of the parameter was something different, and that there are technical alternatives (I even suggested one myself). These situations are not even slightly parallel. But my point is a process and propriety one, not a keep/kill that parameter one: there is an active dispute about this particular parameter+value, |url-status=dead (a dispute in which I'm now neutral), but at least two of you are still going around removing it at will despite vociferous objections. I may disagree strongly (and I do) with the objections to removing |language=en, but I have still stopped removing it until that dispute resolves, whether that happens tomorrow or in ten years.  — SMcCandlish ☏ ¢ 😼  23:41, 4 November 2023 (UTC)

Not refuted at all by anyone, just willfully ihnored. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 5 November 2023 (UTC)

When I and at least one other editor point out that the "need", flagged as the reason to keep doing this stuff all over our articles, is better handled at the other end by the template-translation scripting, that is in fact a refutation. You can try to mount a rebuttal to that refutation, but a false claim that the original proposition was "willfully ignored" is simply untrue and does not consititute a rebuttal of any kind. It's just silly handwaving. I've asked at least 4 times now for vague and also handwavy claims that someone has seen (at some time, somewhere) some other, different translation-related use case to be substantiated with details, so that this alleged use case can be examined, and no one's done it. This is just blowing of smoke, and it's not going to fool anyone.  — SMcCandlish ☏ ¢ 😼  13:29, 5 November 2023 (UTC)

Everything I brought up you just handwaved away as not actually a problem, and swept it under the carpet. As I said above I'm not going into this again, but to say it's been refuted is not true. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:13, 5 November 2023 (UTC)

When someone complains of you engaging in a behavior like handwaving instead of producing evidence, you just using the playground game of "no I'm not, you are!" by using the term back at them reflexively is not a cogent argument, especially when they are not in fact doing it too. Nor is pretending that your evidence or concerns were ignored when they were actually addressed in considerable detail. The fact that the translation issue you want to solve has multiple technical solutions, and one of them is simple and clean (write a better translation script that does sensible things like assume English by default when translating from en.wikipedia) while the other is a total trainwreck (inject redundant code blather millions of times into en.Wikipedia articles) just is as it is. It doesn't make someone somehow in the wrong for pointing this out to you (even if takes multiple tries to get you to hear it). No one is doing you any form of injustice or eganging in bullshitty argumentation tactics with you, and no one is magically obligated to feel convinced by arguments you're impassioned about for some reason, when they don't actually align with the facts at hand and reasonable conclusions drawn from them.  — SMcCandlish ☏ ¢ 😼  15:39, 5 November 2023 (UTC)

I told you how it currently works in the real world and you completely ignored it, as you did any other argument made, at which point I have up trying to convince you as it's obvious you are unwilling to be convinced. You are the one handwaving away anything that doesn't align with your opinion and then saying I haven't produced any argument. I'm sorry if the way the real world works doesn't align with your opinion, but please stop trying to project that onto me. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:39, 5 November 2023 (UTC)

This is more bald-faced proof by repetitive re-assertion, and more childish and nonsensical "maybe I can WP:WIN by taking my opponent's words and just shuffle them around to refer to him instead of me" stuff, so I'm simply not going to respond to you any further.  — SMcCandlish ☏ ¢ 😼  16:55, 5 November 2023 (UTC)

FFS your entire argument against anything I've said has been that it doesn't apply. I already said I was done with this, but you started it up again. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:07, 5 November 2023 (UTC)

Let me try to paraphrase your argument in the various above posts, as best I understand it:

Some automatic tools for helping editors translate wiki pages from French -> English let them copy/paste citation templates unchanged, and a bot comes to clean up the citations. If those citations have language=fr explicitly set on them (is this common?), it will also be set in the English page, but if they don't, then the tools/bot doesn't add it and then the resulting English wiki page won't explicitly specify that citations are in French unless a human editor spends the trivial amount of extra manual effort adding it. You once saw a discussion somewhere which you now can no longer find, in which some editors on the English wikipedia said they want to provide the same service to foreign language translators, so have started adding language=en to their citations. Instead of removing those, we should follow their lead and add language=en widely, because it doesn't take up much space and would provide a nominal service to other language wikis.

Is the above fair, or do I entirely misunderstand what you are arguing for. I also have found it very vague and unconvincing overall. –jacobolus (t) 16:58, 5 November 2023 (UTC)

Fair enough, I don't mind if you disagree (WP:SATISFY), but that's a long way from saying that my arguments have been completely refuted.

As to the translation automation, that's just how it works. If anyone wants to change the real world situation, they should go talk with the people maintaining the translation tools. It's something way beyond the purpose of this talk page.

Also again this thread is not about, and I have not advocated for, the addition of |language= to any cites. I'm against mass removing ones that are already there. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:13, 5 November 2023 (UTC)

I also don't think language=en should be mass removed, because it's annoying churn for a triviality (cf. WP:COSMETICBOT). But often if I manually edit citations that have language=en set on them, I remove it.

Do you have a problem if language=en is removed alongside other more substantive edits? Or is your position that language=en should be left alone whenever it was set? –jacobolus (t) 17:23, 5 November 2023 (UTC)

I don't, as I believe it is useful for certain editors, but I have no great urge to restrict the actions of other editors. I am opposed to "it serves no purposes and should always be removed". -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 5 November 2023 (UTC)

I would still characterize it as serving no purpose. The claimed "purpose" is trivial and almost entirely hypothetical. In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally (which is fine; it does little harm to leave this as a no-op). –jacobolus (t) 18:03, 5 November 2023 (UTC)

In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally Where are you seeing errors? There should be no errors related to |language= but there is a maintenance message when |language= is assigned a value that cs1|2 (MediaWiki) does not recognize (see Category:CS1 maint: unrecognized language).

—Trappist the monk (talk) 18:12, 5 November 2023 (UTC)

Yes, there are no errors. That's the point. It would be bad for language=en to throw an error, even though it doesn't do anything. Making this a no-op that people are free to remove at leisure is an appropriate behavior here. –jacobolus (t) 19:10, 5 November 2023 (UTC)

If you feel it's trivial fair enough, but I'm sorry I really struggle to understand how the issue is hypothetical when it is how the translation of cites currently works. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:13, 5 November 2023 (UTC)

It's hypothetical insofar as something 99% of current citations on on this wiki to English language sources do not include this parameter, so anyone translating an arbitrary English wiki article to Russian or whatever is going to need to manually check every one anyway, so that this is not saving them any appreciable amount of effort.

If we care strongly about this particular group of users, it would be much more useful to fix the English -> X language tool to automatically fill missing language params with the implicit "en" instead of trying to expand the number of references here with language=en explicitly specified.

If that's the only purpose you can come up with for specifying 'language=en', then I say it should be fair game to eliminate them here. But bots and meat bots: please only make this kind of trivial change in a trickle alongside more substantive changes, instead of spamming everyone's watchlists with cosmetic changes. –jacobolus (t) 19:18, 5 November 2023 (UTC)

If you don't believe the use case is noteworthy I won't argue. But I believe we should be encouraging not discouraging the inclusion until someone bothers to change the translation tools. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 5 November 2023 (UTC)

I concur with jocobolus, word-for-word. And as I predicted, the end goal of the other side on this matter is "encouraging ... the inclusion" of |language=en, spreading it to more and more citations, just as I said it was, but I was accused of straw-manning. Are we done now, or is there additional evidence and reasoning to present? This so far has been a complete rehash of the previous cycle.  — SMcCandlish ☏ ¢ 😼  19:55, 5 November 2023 (UTC)

That's what I believe, but as I've said repeatedly I don't support any official change to policy or documentation. Also your comments, particularly "of the other side", just shows the battleground mentality you've shown in this discussion. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:07, 5 November 2023 (UTC)

Every dispute has two sides (if not more). Using plain English is not a transgression. Casting "parting shot" aspersions at people's "mentality" and accusing them of battlelgrounding is not a good look. When I make a proposal (which happens all the time), if I find that is isn't going anywhere despite my efforts to outline my rationale (also happens all the time), I just walk away. There is no need to throw the rude gesture at those who didn't agree with you as if they're bad people for not taking your side (yes side – it's the completely normal term for this) in the discussion. All this personality stuff aside: What we have here is a conflict between a "Why can't we just do something nice for these folks doing hard work" sentiment running into facts that the proposed thing to do is not practical, there is a better solution immediately obvious, and doing it the proposed way will turn into a bigger and bigger mess, harder and harder to clean up later, the longer it operates. Not every well-intentioned idea is one we should go with.  — SMcCandlish ☏ ¢ 😼  20:57, 5 November 2023 (UTC)

I'm not going to read that I don't think it's going to get any better. I'm at a lose as to why a discussion about 12 characters in a cite has become so hostile. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:50, 5 November 2023 (UTC)

I don't think anyone's angry with you, doesn't like you, or is otherwise exhibiting hostility. People just disagree about things, including the weight of evidence and the solidity of reasoning given as rationales in discussions. No one enjoys being disagreed with (probably?), but disagreement happens, and it doesn't mean you're under attack or that people have a personal bone to pick with you. Hope that helps.  — SMcCandlish ☏ ¢ 😼  14:28, 6 November 2023 (UTC)

I'm sorry but I disagree you level of personalisation has been striking. I don't need any help I'm just confused by that level heat over something so unimportant. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:27, 6 November 2023 (UTC)

You keep saying things like "something so unimportant" and "only 12 characters", but two of us have repeatedly pointed out to you that 12 (often 15) characters repeated millions of times is not trivial, but you dodge this and keep re-asserting that it's just 12 characts and unimportant. You must understand that this is frustrating and comes across as refusal to engage meaningfully in the discussion.  — SMcCandlish ☏ ¢ 😼  17:05, 7 November 2023 (UTC)

Unless you believe I am lying I do not have to prove anything. You can accept my points or not, but everytime I have made a point you have attacked the comment not it's substance. So no, I have no more desire to continue this discussion with you.
And yes it is a minor thing. A million times 12 characters is a drop in the ocean of billions of markup characters. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:33, 7 November 2023 (UTC)

An assurance approximately equivalent in utility to |<citation verifies previous sentence>=y. My observance is that the real focus of all this arguing should really be pointed to ensuring that each and every live link that argues it's live (with or without an archive link) to be checked for liveness. I have spent quite some time in the general hitting ostensibly live citations that aren't (for which I have done the good duty of finding them appropriate archive URLs). Izno (talk) 21:17, 4 November 2023 (UTC)

Ah, but |<citation verifies previous sentence>=y gives us license to remove driveby {{cn}} tags slapped down in haste by editors with no time to check the source cited one sentence later. Folly Mox (talk) 23:29, 4 November 2023 (UTC)

Just a minor point - but language=en will have occasional use to the reader - when the title of a source isn't in the English language but the source is, or in the case of an English language article in a journal that is primarilary written in a non-English language. While these occasions may be rare they do occasionally happen.Nigel Ish (talk) 23:14, 26 December 2023 (UTC)

I read the entire thread about url-status-dead (minus the namecalling and tangential topic of language=en) and here is my analysis.

When you write for a computer, you have to give explicit directions such as "If A, then B, else C". For example: If url-status is live, then use the url, else use the archive-url.

But HUMANS don't think like that! They read "url-status=live" and they think "ah hah, that is the primary url". Or they read "url-status=dead" and they think "oh dear, original url is dead so I'll use the archived url". But when HUMAN reads "(blank)", they think "oh no, I'm not sure which one of the two urls is the correct one!" And that is because omissions are AMBIGUOUS, and a single-sentence inserted into the [very lengthy] written instructions of Template:Cite web simply isn't sufficient to turn the average wiki editor into a computer programming thinker (if they even notice that single sentence).

Those of you arguing for the machine-read version and removing url-status=dead as obsolete or null, are dealing only in computer programming concepts. Those of you arguing for the human editor to keep url-status=dead are recognizing the human mind's natural way of dealing with omitted information. Even the experienced long time wiki editors are arguing for keeping url-status=dead as the more natural and clear communication to editors. We write wiki policy for editors... not computer programs. We get consensus from editors, not the few programmers, because the website is used by the editors every single day.

Since programming is the province of computers, BOTs, and rendering software, and programming them need only involve the few techies on the website, and only involve programming the defaults once and done, I fail to understand why some of the tech-minded are arguing so hard to continue removing an explicitly written parameter that seems so helpful or valuable to human editors every single day, for every article, for every citation. The programmer may be done with their work, but the human editor has to deal with it over and over again. Removing url-status=dead just because "the computer program doesn't need it" or "we never thought the humans would misunderstand (or ever find useful) this parameter we created for our computer program" are not just lame arguments, but ones which ignore the real life consequences: ongoing confusion, misunderstanding, uncertainty, and extra effort (to name just a few).

Yes, I use url-status=dead and I like it. I tend to cut-and-paste urls directly from the CODE and paste them in a new browser window, rather than click on urls from the rendered wiki page. I'm sure I'm not alone in that practice.   ▶ I am Grorp ◀ 08:34, 21 January 2024 (UTC)

Thanks. Doug Weller talk 14:37, 20 January 2024 (UTC)

You are going to have to be more explicit than that. If you are talking about citation filling tools, this venue is not the correct place. WP:RefToolbar and that abomination that is the visual editor can autofill template parameters (sometimes even correctly). Those tools are outside of the cs1|2 bailiwick.

—Trappist the monk (talk) 15:09, 20 January 2024 (UTC)

@Trappist the monk Sorry, remiss of me not to give an example. See Kenneth_Feder#Books. I hate the visual editor. I didn't think ref toolbar did this. Doug Weller talk 17:17, 20 January 2024 (UTC)

It ain't perfect. For example, giving toolbar ISBN 978-0-313-37918-5 and clicking the quizzing glass gets this:

{{cite book |last1=Feder |first1=Kenneth L. |title=Encyclopedia of dubious archaeology: from Atlantis to the Walam Olum |date=2011 |publisher=Greenwood |location=Santa Barbara, Calif. |isbn=978-0-313-37918-5}}

which is sort of similar to your version:

{{cite book |first=Kenneth |last=Feder |year=2010 |title=Encyclopedia of Dubious Archaeology: From Atlantis to the Walam Olum |url=https://archive.org/details/encyclopediaofdu0000fede |url-access=registration |publisher=[[Greenwood Publishing Group]] |isbn=978-0-313-37918-5}}

no |url=, no |url-access=; |date=, |first=, |publisher=, and |title= have different values; toolbar gives |location=.

But, giving toolbar ISBN 978-1-4422-6312-3 and clicking the quizzing glass gets nothing.

Do not trust what toolbar gives you. Sometimes you get a good cs1|2 template; sometimes you get junk.

—Trappist the monk (talk) 17:37, 20 January 2024 (UTC)

@Doug Weller: The ProveIt gadget offers the same feature beyond the top 4 citation templates. The RefToolbar, ProveIt, the Visual Editor, and so on all rely on Citoid. If you need a URL for {{cite book}}, you have to feed Citoid the URL (not the ISBN) and the output will depend on how well that URL formats the data. Rjjⁱⁱⁱ (talk) 18:20, 20 January 2024 (UTC)

Umm, what? URLs don't format data...

—Trappist the monk (talk) 18:27, 20 January 2024 (UTC)

@Trappist the monk: How well [the web page at] that URL formats the data.

On archive.org some uploads have really clear and accurate information where you may have a small error (location and publisher are combined on the example above) or even no errors. Other pages will provide no information. It's not uncommon when using a URL though to have Citoid provide seemingly random information, especially in the title and author parameters. Rjjⁱⁱⁱ (talk) 18:47, 20 January 2024 (UTC)

Using Google books for autofilling most of the fields usually works, searching "isbn:978-1-4422-6312-3" with the books filter gives you one work[6] using that URL (https://books.google.co.uk/books?id=t4fKjwEACAAJ) in reftool bar should autopopulate most fields. Obviously it may require some manual intervention, and you can always remove or replace the URL with another one afterwards. -- LCU ActivelyDisinterested «@» °∆t° 23:13, 20 January 2024 (UTC)

Tried to add Proveit, nothing happened. I clicked the "use Wikiedit' button on the right and n now on Chrome the screen is partially covered, on the left with the Logo etc menu, and I can't click on the right hand buttons because they are covered by the Search WIkipedia field. Not asking for help here, just saying what happened. I'll carry on working with other browsers, this is Chrome specific and has happened before, presumably an update. Doug Weller talk 14:40, 21 January 2024 (UTC)

@ActivelyDisinterested Thanks, that is exactly what I need. I get some of the details, add the others, delete the <ref> and <ref/> and as the cliche goes, Bob's your uncle. I just have to avoid Chrome for a while.:-) Doug Weller talk 15:55, 21 January 2024 (UTC)

I'm currently working on Adventure Unlimited and there's a citation to a 1968 newspaper article with date and page number. However I have found the newspaper of that masthead from that date in the Google News archives and the named heading doesn't seem to appear in the newspaper at all on that date. Is it best to remove the citation, or otherwise what maintenance template would be best to use in this situation? The documentation at {{Failed verification}} says that the citation should still be somewhat relevant. Reader781 (talk) 01:22, 22 January 2024 (UTC)

Which citation in particular is this? And using e.g., Wikipedia:WikiBlame to find the editor who added that source, can you tag them in the talk page and figure out where the possible disconnect might arise from? It might be that Google News didn't digitize supplements, that there are different editions, that the date got mistyped, etc., so I wouldn't delete it outright but I'm not sure the best tag to use -- {{Citation not found}} sounds like it might be applicable but that also isn't right for this situation where you just are having trouble finding the source in the first place. Umimmak (talk) 01:32, 22 January 2024 (UTC)

I often just use {{clarify}} with an extensive description of the problem in |reason=.

—Trappist the monk (talk) 01:40, 22 January 2024 (UTC)

Oh that's a good start, @Trappist the monk. {{clarify}} mentions {{specify}} for use with sourcing issues too.

@Umimmak it's reference No. 23, "Magical Art of Acting and Eating", from The Age. I'll see what WikiBlame turns up and go from there, otherwise use either one of the above-mentioned templates. Thanks to the both of you. Reader781 (talk) 01:48, 22 January 2024 (UTC)

Well I was able to find the source in question -- seems to be an accurate citation? Wednesday January 29, 1969, The Age, "Magical Art of Acting and Eating" [7] [8] Umimmak (talk) 02:06, 22 January 2024 (UTC)

@Reader781: realized I forgot to ping Umimmak (talk) 02:08, 22 January 2024 (UTC)

A-ha! It was a date typo - 1969 not 1968. Thank you so much for finding this. Not sure why it didn't occur to me to search for it by name, but thanks again! I was just having a bite to eat before continuing, I'll add this to my edit in progress. Reader781 (talk) 02:13, 22 January 2024 (UTC)

Ah there we go! Not an accurate citation then, I mentally fixed it while reading I suppose, but that explains the discrepancy. :) Umimmak (talk) 02:15, 22 January 2024 (UTC)

I keep seeing cases where the work parameter is ignored in {{cite encyclopedia}}, {{cite book}}, and {{cite journal}}. Latest example, there are two occurrences in List of music students by teacher: G to J: Hagen, S. A. E. (1900)... and MRS. ROBINSON-DUFF VOCAL TEACHER, DIES... (that citation needs other attention too). The documentation for cite encylopedia says that |work= is an alias for |encyclopedia=, so I guess either there is a coding problem or a deprecation has not been correctly handled. -- Mirokado (talk) 22:47, 7 January 2024 (UTC)

For Mrs Robinson, {{cite work}} is a redirect to {{cite book}} but the source is The New York Times so {{cite book}} is inappropriate; use {{cite news}}.

The template documentation for |encyclopedia= at {{cite encyclopedia}} does not say that |encyclopedia= is an alias of |work=. See Template:Cite encyclopedia § Title. That documentation has problems (mentions of |script-title= and |title=) but claims that |encyclopedia= is an alias of |work= is not one of them.

—Trappist the monk (talk) 23:09, 7 January 2024 (UTC)

Hello Trappist the monk: for {{cite book}}, the documentation indeed requires |title= and does not suggest |work= as an alias, so that is OK. I recently had to make this change which explains the confusion here. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

The encyclopedia line in the Template parameters table in the Templatedata section in the documentation for {{cite encyclopedia}} says "Encyclopedia ... Title of the source; may be wikilinked; displays in italics; alias of 'work' "

Here is an example of a recent correction for {{cite encyclopedia}}. The previous version had been working correctly with |work=. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

The template data is incredibly out of date, it also suggests setting |ref= to 'harv' to generate an anchor point for short form refs. -- LCU ActivelyDisinterested «@» °∆t° 10:44, 8 January 2024 (UTC)

I guess you know that the previous version had been working correctly with |work= because you switched those templates away from |encyclopedia= with this edit. Why did you do that? That would have been a pointless edit except that you also changed a {{cite web}} to {{cite encyclopedia}}.

Some of us have gotten our asses chewed enough that we are gun-shy when it comes to touching TemplateData. I don't use the abomination that is Visual Editor so I don't bother looking at TemplateData. The TemplateData are not protected so if they are out of sync with the real template documentation (such as it is), feel free to apply the necessary fixes.

—Trappist the monk (talk) 14:38, 8 January 2024 (UTC)

I've come to prefer |work= to the alternatives, it is shorter and one name for the equivalent information.

I can try to bring the template data more up to date...

There really is a problem with cite encyclopedia as shown in the following expansions:

using |encyclopedia=: "Gerbils". Too Much Information.

using |work=: Gerbils. {{cite encyclopedia}}: |work= ignored (help)

in the latter case, citations which used to be correct are now missing the work/encyclopedia information in the display. -- Mirokado (talk) 08:06, 11 January 2024 (UTC)

A search for the error text "{{cite encyclopedia}}: |work= ignored" (with the quotes) currently shows 759 matches.

The corresponding search for cite book "{{cite book}}: |work= ignored" shows 17790 matches. -- Mirokado (talk) 10:15, 11 January 2024 (UTC)

Unfortunately the cite book errors have no easy fix, it's been stuffed with all kinds of things other time. Having an error message to show that something is wrong is definitely a good thing. Whether it's title, series, or even the website used in the courtesy url, they all need to be corrected. Gnomes will do so over time, as with other error messages. -- LCU ActivelyDisinterested «@» °∆t° 12:32, 11 January 2024 (UTC)

Taking a quick look at the cite encyclopedia errors it appears editors have been misusing {{cite contribution}} (a redirect of cite encyclopedia) to cite chapters in a book. But with so few errors it won't take long to clear them. -- LCU ActivelyDisinterested «@» °∆t° 12:53, 11 January 2024 (UTC)

Mirokado, this problem in general was discussed on this page a few months ago at Help talk:Citation Style 1/Archive 91 § Enabling |work= as a |title= alias in Template:Cite book, where I was the editor arguing most similarly to your current position. Following that thread, I actually undertook to start fixing errors in Category:CS1 errors: periodical ignored (23,143).

It turns out that – although I share your fondness for the |work= parameter for ease of entry – nobody knows what |work= is for. In addition to the "name of broader work" the source appears in, I've seen |work= hold the value of – I think – literally every other parameter: publisher, author, editor, translator, date, volume, chapter, page, quote, location, series, edition, via, and probably some I've forgotten. Maybe not url or doi.

About half of the errors in the linked maintenance category seem to have been introduced by Citation bot changing template type without changing parameter names.

Anyway now I'm broadly in agreement with the thread somewhere above about deprecating {{cite encyclopedia}} entirely, converting them all to {{cite book}} or {{cite web}} as appropriate, and would further support deprecating the |work= alias in every template once the maintenance categories are a bit more cleaned out. It's apparently too confusing. Folly Mox (talk) 13:33, 11 January 2024 (UTC)

Thank you Folly Mox for the detailed reply. I fully agree with your comments in the linked section. Clearly, as usual, things are more complicated than I expected. I've started looking through these errors (currently 681 left): this is not a completely futile exercise as some of the articles have other more substantial problems, and I learn about all sorts of things as I go. -- Mirokado (talk) 12:12, 24 January 2024 (UTC)

Mirokado: If |work= is being ignored in {{cite journal}}, please link to an example. It's working for me: "Title". Work.. – Jonesey95 (talk) 23:51, 7 January 2024 (UTC)

Hello Jonesey95: you are right, sorry. The errors I have been seeing are all in {{cite encyclopedia}} and {{cite book}} and I have also confirmed that cite journal works in the sandbox. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

Yes, |work= is not valid in {{cite book}}. |title= or |series= is typically what is needed. If you link to a specific example in an article, I can help you fix it. {{Cite encyclopedia}} is sometimes above my pay grade, though; it's a strange little beast. – Jonesey95 (talk) 16:22, 8 January 2024 (UTC)

@Mirokado:  Fixed the references in the List of music students by teacher: G to J article in these edits. GoingBatty (talk) 01:39, 8 January 2024 (UTC)

Hello GoingBatty, thanks for those corrections. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

See also #cite encyclopedia thread, above; I think a good argument can be made to just get rid of {{cite encyclopedia}}. Every instance of it should be replaceable with {{cite book}} for an actual book-form encyclopedia or {{cite web}} for an online-only work. It's a strange and useless thing that isn't identifying a publication by medium/format but by what "societal purpose" or "editorial intent" its publishers declare it has.  — SMcCandlish ☏ ¢ 😼  22:26, 8 January 2024 (UTC)

I like that idea. Are there any substantial formatting differences in the visible output versus the output of the two more common template types? Folly Mox (talk) 04:26, 9 January 2024 (UTC)

Here's test data, using every parameter that is documented for {{cite encyclopedia}} (other than mutually exclusive ones like |page= and |pages= and |at= that can't all be used at once; and just enough authors to test the functionality): User:SMcCandlish/Cite encyclopedia test. If you "translate" the parameters correctly, the output from {{cite book}} is exactly identical. However {{cite web}} moves the editor name, for unknown reasons, and it also drops |volume= which is probably not desirable, since some online works can be released with volume numbers, even if it's not common. Until that were resolved, the way to preserve a volume number for an online-only encyclopedia that had such numbering (if there are any) would probably be to combine it with the |page[s]= data, as something like |at=Vol. 3, pp. 123–125, though it will not appear in exactly the same spot in the citation as it would with {{cite book}}. I was pleasantly surpised that if you do |chapter-url= in {{cite book}}, the |archive-url= automatically works with it, including for |url-status=dead (at least if there's not a competing |url=; didn't test what happens then, since the {{cite encyclopedia}} test doesn't involve multiple URLs; it possible that template can handle them somehow, but there's no documentation suggesting this).  — SMcCandlish ☏ ¢ 😼  15:32, 9 January 2024 (UTC)

PS: I have not pored over the COinS metadata in the output; it's possible there are one or more other differences that are not visible to human readers.  — SMcCandlish ☏ ¢ 😼  15:48, 9 January 2024 (UTC)

I was mistaken about changing to {{cite book}} affecting anything. I don't fully understand the COinS, but a text comparison tool shows both templates giving the same output (with some displayed parameters from {{cite web}} seeming to be absent in the COinS).

Regarding "However {{cite web}} moves the editor name, for unknown reasons", that's default rendering given by {{Citation}}, I think.

Regarding, "it also drops |volume= which is probably not desirable", I think {{cite web}} has never supported |volume= or |issue=. The documentation for it, says to use a different template.[9] I would guess a preference for |access-date= which is harder to get wrong?

Unrelated, but while trying to see why {{cite web}} doesn't support |volume=, I came across several discussions (like this one[10]) showing a strong consensus to have {{cite magazine}} as a separate template for how it renders page/volume/issue. Rjjⁱⁱⁱ (talk) 22:28, 11 January 2024 (UTC)

The documentation for {{Cite interview}} says it supports a via= field, but when I edit the template in the visual editor, there's no via listed. What's wrong? RoySmith (talk) 18:51, 22 January 2024 (UTC)

@RoySmith: Hi there! {{Cite interview}} does indeed support |via=

{{cite interview |title=Title |via=ViaTest}} generates "Title" (Interview) – via ViaTest.

Therefore, I added |via= to the Template data in this edit to Template:Cite interview/doc, so you should now see it when adding the template in the VisualEditor. I haven't checked, but there are probably additional opportunities to improve the documentation and/or TemplateData. GoingBatty (talk) 19:26, 22 January 2024 (UTC)

Yup, it now shows up as "Published Via", although calling it just plain "Via" would be more in line with the name used in other templates. Thanks for fixing this! RoySmith (talk) 21:48, 22 January 2024 (UTC)

@RoySmith: I attempted to make the Template data in Template:Cite interview/doc consistent with Template:Cite web/doc, which uses "Published via", but I see I got the capitalization wrong. Feel free to change Template:Cite interview/doc and/or Template:Cite web/doc to whatever you prefer. GoingBatty (talk) 22:43, 24 January 2024 (UTC)

Got it, thanks. I see now that the actual field name is indeed "via", it's just the display name in the UI, so that's no big deal. RoySmith (talk) 23:01, 24 January 2024 (UTC)

I just stumbled upon doi:10.3410/f.736364175.793573144 in List of biological databases. I had to fix this reference (missing |journal=) and discovered that the source requires 'free' registration. To my mind, any source that requires me to give over personally identifying information, is not 'free'. So, I think that doi registrant 3410 should be removed from Module:Citation/CS1/Configuration and any template with that registrant in article namespace should be edited to remove the |doi-access=free parameter (currently ~85 articles).

—Trappist the monk (talk) 14:56, 25 January 2024 (UTC)

I'm note sure about that link, but doi:10.1093/molbev/msz147 should be the DOI used. I'll investigate a bit. Headbomb {t · c · p · b} 16:42, 27 January 2024 (UTC)

Seems free registration is required to read free non-F1000 papers (e.g. doi:10.1093/molbev/msz147) with F1000 DOIs (doi:10.3410/f.736364175.793573144) – an abhorrent practice – and that actual F1000 papers with F1000 DOIs don't require registration (e.g. doi:10.3410/M2-49). The fix here seems to update the papers to use their legit DOI. Headbomb {t · c · p · b} 16:47, 27 January 2024 (UTC)

{{citation}} should be able to accept |mode=cs1 and simultaneously |postscript=none without emitting a maintenance message. Alas, that is not what is happening now. I discovered this when attempting a fix at {{NDB}} because that template, when written with |mode=cs1, emits .; as the postscript separator.

I have hacked on the module sandbox so that {{citation}} with both |mode=cs1 and |postscript=none works properly:

—Trappist the monk (talk) 16:36, 27 January 2024 (UTC)

If this citation is included in an article

^[1]

it gives the following message that can be seen in page preview mode: "Script warning: One or more {{cite journal}} templates have maintenance messages; messages may be hidden (help)."

I have determined (through the time-wasting process of commenting out citations individually to find the offending source) that it is the doi that creates the error; if the doi is left out of the citation, the warning message does not appear. The doi appears to be unremarkable and functional, so I have no idea what the issue is. This is not the only time I've had this problem, so I can dig up more examples if needed. The affected article for the above example is Cladoniaceae. Esculenta (talk) 18:54, 27 January 2024 (UTC)

The script warning message that you quote has a help link. When you click that link you end up at Help:CS1 errors § Controlling error message display. Normally hidden maintenance messages can be unhidden by following the instructions on that page.

—Trappist the monk (talk) 19:27, 27 January 2024 (UTC)

Next time it happens, check the categories for unusual behaviour; in this case you'd have seen Category:CS1 maint: unflagged free DOI, and the solution is to set the "doi-access=free" parameter. Esculenta (talk) 20:53, 27 January 2024 (UTC)

@Esculenta: The hidden maintenance message states "CS1 maint: unflagged free DOI". To remove it, try adding |doi-access=free, like this.^[2] GoingBatty (talk) 21:10, 27 January 2024 (UTC)

I think I'm seeing this same error on Impact factor (remoteref: ^[40], reproduced below^[1] for convenience)

The reference uses the author parameter, but I've found that using last results in the same error message.^[2] If I'm reading the docs correctly, author is supposed to be a valid alias for last, and the latter is the parameter one is supposed to use for e.g. "The PLoS Medicine Editors":

Authors

last: Surname of a single author. Do not wikilink—use author-link instead. For corporate authors or authors for whom only one name is listed by the source, use last or one of its aliases (e.g. |author=Bono). Aliases: surname, author, last1, surname1, author1.

• author: 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.

Also, I checked the archives, but please let me know if I missed an existing thread about this (or if I can improve my post in general)!

– spida-tarbell ❀ (talk) (contribs) 23:17, 28 January 2024 (UTC)

Help:CS1 errors#generic name reads False positives are possible. When the name is valid, wrap the parameter value in the accept-this-as-written markup: :|author=((Super User)), so I guess you could just have:

• {{cite journal |author=((The PLoS Medicine Editors)) |title=The impact factor game |journal=PLoS Medicine}}
• The PLoS Medicine Editors. "The impact factor game". PLoS Medicine.

Umimmak (talk) 23:26, 28 January 2024 (UTC)

(edit conflict)

Kind of unclear what you want from us. Yes, |author= is an alias of |last=. Use |author= for corporate or 'group' names. The error message appears because |author=The PLoS Medicine Editors contains Editors which is considered to be a generic 'name'. When a generic name is actually legitimate, rewrite the parameter value to suppress the error message using the accept-this-as-written markup: |author=((The PLoS Medicine Editors)).

—Trappist the monk (talk) 23:33, 28 January 2024 (UTC)

The accept-as-written is relatively new - perhaps added when error checking became more aggressive. There is no mention at {{cite journal}} that this applies to the author or editor fields. What is the best way to update the individual citation templates involved? StarryGrandma (talk) 23:50, 28 January 2024 (UTC)

Not really 'new'. The markup was first proposed at Help talk:Citation Style 1/Archive 8 § Corporate authors and |vauthors= 10 May 2015 and implemented 25 July 2015.

Including a statement about what the ((..)) markup does for each parameter seems like documentation bloat. Perhaps for each affected parameter, we add a simple link to the documentation at Help:Citation Style 1:

Supports accept-this-as-written markup.

or somesuch. If you know of a better way, say it.

—Trappist the monk (talk) 00:21, 29 January 2024 (UTC)

 Added in this edit. Adjust as you see fit. GoingBatty (talk) 01:52, 29 January 2024 (UTC)

Ah, I hadn't recognized that was the trigger for the "generic name." And I had meant to ask why this is happening and what I should change to fix or head off the error. Thank you. – spida-tarbell ❀ (talk) (contribs) 01:59, 29 January 2024 (UTC)

@Spida-tarbell: Another option is to remove "The PLoS Medicine Editors" from the citation. I don't see what value it provides to the reader of the Wikipedia article. GoingBatty (talk) 23:40, 28 January 2024 (UTC)

Because it lets them know who wrote the article, and that it was specifically the PLoS Medical editors. Why would it ever be useful to the reader to remove information from a citation; that makes it ambiguous between an editor forgetting to add a parameter in the citation and having no credited author (which is not the case here; there is an explicit byline). Umimmak (talk) 23:48, 28 January 2024 (UTC)

It is the standard for citations in this area to include whatever the journal says the authors are. Part of what we do is attribution, crediting authors, even if they are a committee. StarryGrandma (talk) 23:53, 28 January 2024 (UTC)

Point taken. Then you'd want the formatting to be the same as whatever the journal says the authors are:

• {{cite journal |author=((The ''PLoS Medicine'' Editors)) |title=The impact factor game |journal=PLoS Medicine}}
• The PLoS Medicine Editors. "The impact factor game". PLoS Medicine.

GoingBatty (talk) 23:58, 28 January 2024 (UTC)

Except that doing so produces corrupt metadata:

&rft.au=The+%27%27PLoS+Medicine%27%27+Editors

We allow italic markup in |title= so no doubt, we can use the same or similar mechanism for name-list parameters. Is there sufficient need to do that? It ain't free; every name would have to be tested.

—Trappist the monk (talk) 00:21, 29 January 2024 (UTC)

@Trappist the monk: Thank you. I've updated the documentation according to the information you provided. GoingBatty (talk) 00:30, 29 January 2024 (UTC)

Thank you all! I've updated the reference and, in case it's helpful, added a comment noting that italics corrupt metadata. – spida-tarbell ❀ (talk) (contribs) 02:30, 29 January 2024 (UTC)

This week I'm cleaning up dozens of edits like this one where User:AnomieBOT mangles a {{cita web}} reference that is missing (due to a previous human error) the title field and displaying a red error message that requires manual attention. This is difficult to recover from, because the edit often cannot be undone due to later edits, and I'm sure for most editors it's not obvious that they need to dig through the article history to recover the URL and find a title for it. I can see three fixes for this:

1. Edit the template so that when it experiences an error of this type it returns more suitable output that retains the original parameters but only displays the error message to readers. (Maybe adding "|nosubst=1" so bots don't keep trying to change it, if it's not converted to {{cite web}}?)
2. Add logic to AnomieBOT to detect red or orange error messages and refrain from subst-ing those instances.
3. Remove Template:Cite web/Italian or Spanish (to which Template:Cita web redirects) from Category:Wikipedia templates to be automatically substituted.

@Anomie: Do you have stats on how many times a month or whatever this particular template is subst'd? That would help decide if doing 3 would just make a ton of work for editors or if it would be better on balance. Also especially interested in your thoughts on 2. Thanks! -- Beland (talk) 20:27, 24 January 2024 (UTC)

This is not the fault of AnomieBOT. {{cita web}} calls Module:CS1 translator which attempts to translate what it expects is a more-or-less properly formatted template with Spanish- or Italian-language parameter names. The module uses |título= (Spanish) or |titolo= (Italian) to choose which language to use when translating the other parameters in the template. In this case, the editor apparently manually translated everything except the template name (or committed that most heinous of sins, a typo).

I'll think about how to fix this problem (which will also apply to {{cita news}} and {{cita libro}}).

As I write this, there are seven articles displaying the error message (search)

—Trappist the monk (talk) 21:04, 24 January 2024 (UTC)

Five a few hours later, 4 where from a cite webb with a typo and the last was unrelated to this issue (junk copied from itwiki without the editor doing any checks). -- LCU ActivelyDisinterested «@» °∆t° 02:36, 25 January 2024 (UTC)

AnomieBOT's logs for January so far show 135 mentions of substing that template, and the logs for December show 160. I don't keep logs further back than that. IMO the best solution would be to either turn off bot-substing for the template or fix it so its substed output in this situation is more useful. Note that adding |nosubst=1 to the output might eventually result in over 100 unsubsted transclusions, which would stop the bot from substing that template entirely until someone cleans it up. Anomie⚔ 23:40, 24 January 2024 (UTC)

Given the high likelihood of typos as the cause for {{cita web}} and {{cita news}}, wouldn't it be more prudent that bots not attempt to "fix" these? -- Michael Bednarek (talk) 01:14, 25 January 2024 (UTC)

This is not a bot issue. AnomieBOT just does substing that MediaWiki can't (apparently won't ever) do.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

Is there anyway for AnomieBOT to check for |title= before doing the substitution, and if it does just correct the typo (cita -> cite)? -- LCU ActivelyDisinterested «@» °∆t° 02:18, 25 January 2024 (UTC)

It is not AnomieBOT's responsibility to do such checks. AnomieBOT's purpose in all of this is to subst an English cs1|2 template in place of the original non-English template and nothing more.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

I have hacked Module:CS1 translator so that when {{cita libro}}, {{cita news}}, and {{cita web}} do not have either of |título= (Spanish) or |titolo= (Italian), the module translates the template name to {{cite book/subst}}, {{cite news/subst}}, or {{cite web/subst}} as appropriate. If, as in the example case, the template was properly translated by hand except for the template name, AnomieBOT will subst the template name to the canonical {{cite book}}, {{cite news}}, or {{cite web}} as appropriate.

This version of my sandbox has the originally offending template. The error message that the previous version of the module emitted is not present. A subsequent version of my sandbox shows the template after AnomieBOT has done the substing.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

Great work thanks Trappist the monk, and apologies for misunderstanding the technical situation. -- LCU ActivelyDisinterested «@» °∆t° 19:32, 25 January 2024 (UTC)

Woo, thanks for the quick fix! -- Beland (talk) 23:42, 30 January 2024 (UTC)

I want to cite the author of the Introduction to this reprint of an old book. I have this format, {{cite book |last1=Widmer |first1=Randolph J. |title=Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida |year=2000 |publisher=The University Press of Florida |location=Gainesville, Florida |isbn=0-8130-1791-2 |pages=i-xxii |chapter-url=https://books.google.com/books?id=gRiwKU4ikkkC&q=van+beck+key+marco&pg=PR10 |author2=Frank Hamilton Cushing |author-link=Frank Hamilton Cushing |orig-date=1896 |chapter=Introduction}} in the article, but I cannot figure out how to show Cushing as the author of the original book without making it look like Widmer and Cushing are co-authors. My apologies if this has been covered before, but I haven't figured out a search term that finds such a discussion in the archives. Donald Albury 01:09, 30 January 2024 (UTC)

{{cite book |contributor-last1=Widmer |contributor-first1=Randolph J. |title=Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida |year=2000 |publisher=The University Press of Florida |location=Gainesville, Florida |isbn=0-8130-1791-2 |pages=i-xxii |chapter-url=https://books.google.com/books?id=gRiwKU4ikkkC&q=van+beck+key+marco&pg=PR10 |first=Frank Hamilton |last=Cushing |author-link=Frank Hamilton Cushing |orig-date=1896 |contribution=Introduction}}

Widmer, Randolph J. (2000) [1896]. Introduction. Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida. By Cushing, Frank Hamilton. Gainesville, Florida: The University Press of Florida. pp. i–xxii. ISBN 0-8130-1791-2.

—Trappist the monk (talk) 01:21, 30 January 2024 (UTC)

Really? Surely Widmer is the author, the only author. Cushing just wrote a new intro. So (unless the chapter cited is the intro, which it isn't) I see no reason to even mention Cushing unless it would be reasonable to declare him as an editor? --𝕁𝕄𝔽 (talk) 11:50, 30 January 2024 (UTC)

So (unless the chapter cited is the intro, which it isn't) Umm, are you sure? First sentence of OP's post (emphasis added):

I want to cite the author of the Introduction to this reprint of an old book.

In cs1|2, a separately authored contribution (the introduction) to the work of a primary author (Cushing) goes in |contribution=. The author of the contribution (Widmer) is named using |contributor= parameters. OP's template is a bit misleading in that it specifies a broader page range than it should: |pages=i-xxii when it should be |pages=ix-xxii (for the whole introduction) or perhaps better |page=x which agrees with the template's |url= value.

—Trappist the monk (talk) 13:23, 30 January 2024 (UTC)

That's it! Thank you. Donald Albury 13:28, 30 January 2024 (UTC)

So, what exactly is the use case of |title-link= in {{cite book}}? Why would we do {{cite book |title=The Elements of Style |title-link=The Elements of Style |...}} instead of {{cite book |title=[[The Elements of Style]] |...}}? The latter seems to overwhelmingly dominate; I hardly ever see |title-link=.  — SMcCandlish ☏ ¢ 😼  22:45, 12 January 2024 (UTC)

My vague impression is that splitting them out in this way makes it easier for the template to generate the zotero structured metadata that nobody actually uses. Why we need to generate this metadata and why the template can't split the link from the text itself are obvious questions. —David Eppstein (talk) 23:29, 12 January 2024 (UTC)

|title-link= was apparently new with the lua version of cs1|2:

I found this (malformed) template in Global Positioning System which may (or may not) illustrate a reason that |title-link= exists:

{{cite book|title=The American Practical Navigator – Chapter 11 ''Satellite Navigation''|author=Nathaniel Bowditch|publisher=United States government|year=2002|title-link=s:The American Practical Navigator}}

'"`UNIQ--templatestyles-000000B1-QINU`"'<cite id="CITEREFNathaniel_Bowditch2002" class="citation book cs1">Nathaniel Bowditch (2002). <span class="cs1-ws-icon" title="s:The American Practical Navigator">[https://en.wikisource.org/wiki/The_American_Practical_Navigator ''The American Practical Navigator – Chapter 11 ''Satellite Navigation''<span></span>''&nbsp;]</span>. United States government.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=The+American+Practical+Navigator+%E2%80%93+Chapter+11+Satellite+Navigation&rft.pub=United+States+government&rft.date=2002&rft.au=Nathaniel+Bowditch&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+93" class="Z3988"></span>

Nathaniel Bowditch (2002). The American Practical Navigator – Chapter 11 Satellite Navigation . United States government.

Here, I have rewritten to omit |title-link= by including the link in |title=:

{{cite book|title=[[s:The American Practical Navigator|The American Practical Navigator – Chapter 11 ''Satellite Navigation'']]|author=Nathaniel Bowditch|publisher=United States government|year=2002}}

'"`UNIQ--templatestyles-000000B5-QINU`"'<cite id="CITEREFNathaniel_Bowditch2002" class="citation book cs1">Nathaniel Bowditch (2002). <span class="cs1-ws-icon" title="s:The American Practical Navigator">[https://en.wikisource.org/wiki/The_American_Practical_Navigator ''The American Practical Navigator – Chapter 11 ''Satellite Navigation''''&nbsp;]</span>. United States government.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=The+American+Practical+Navigator+%E2%80%93+Chapter+11+Satellite+Navigation&rft.pub=United+States+government&rft.date=2002&rft.au=Nathaniel+Bowditch&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+93" class="Z3988"></span>

Nathaniel Bowditch (2002). The American Practical Navigator – Chapter 11 Satellite Navigation. United States government.

The COinS metadata are the same for both of these templates. The visual renderings are not the same.

This search finds about 26,000 articles that use |title-link=.

—Trappist the monk (talk) 00:25, 13 January 2024 (UTC)

It's not like |author-link= which is required due to |first= and |last=. It opens Pandora's Box, do we also have |publisher-link=, |location-link=? It's added complexity, unless really needed like authors. -- GreenC 02:06, 13 January 2024 (UTC)

And I can't see any pratical purpose at all to including a cutesy icon. Is it pulling a favicon from the site or something? We shouldn't have any images in citation unless we really, really, really think we badly need them, e.g. to indicate paywalled resources.  — SMcCandlish ☏ ¢ 😼  09:22, 3 February 2024 (UTC)

When you set the bibcode parameter as well as postcript, the bibcode does not display or link properly in the created citations: {{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=;}} displays:

• Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;

This is clearly not displaying correctly, and it gets even worse when you add text after the template; see {{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=;}} also published in ''[[Survey Review]]''. ''' 19''' (144): 50–51. {{doi|10.1179/sre.1967.19.144.50}}.

• Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.; also published in Survey Review. 19 (144): 50–51. doi:10.1179/sre.1967.19.144.50.

Now the link works, but also adds the link to the following text. And the doi at the end of the following text does not link properly. BhamBoi (talk) 00:30, 1 February 2024 (UTC)

Some bugs just take a while to show themselves. This one has been a sleeper since March 2013 (diff).

What is happening is that when there is a postscript, following a bibcode identifier and the identifier's last character is a dot, the code indiscriminately removes the bibcode link's closing ]. That, of course, breaks the rendering. If the last character of the bibcode identifier is not a dot, the live code works as it should:

{{cite book |title=Title |bibcode=1967QJRAS...8..292a |postscript=;}}

Title. Bibcode:1967QJRAS...8..292a;

The code in the live module was supposed to remove the terminal separator character (for cs1, a dot). I have tweaked the sandbox so that the code will only remove a terminal dot:

{{citation}} comparison to show that I didn't break anything.

For i18n, the internal variable sepc can be something other than a dot. The module will remove that terminator when sepc is not defined as a dot in Module:Citation/CS1/Configuration.

—Trappist the monk (talk) 15:21, 1 February 2024 (UTC)

If I'm including the citation in an article, what should I do for now? BhamBoi (talk) 00:36, 2 February 2024 (UTC)

The obvious workaround is:

{{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=none}};

Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;

—Trappist the monk (talk) 00:44, 2 February 2024 (UTC)

Thanks BhamBoi (talk) 00:47, 2 February 2024 (UTC)

* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.

and

* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |number=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.

are both currently displaying as

• Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, vol. 81, Chicago: University of Chicago Press, pp. 148–153, JSTOR 269789.

instead of providing the issue number either "correctly" (no. 2) or in the uglier compact formatting in parentheses after the volume. Kindly fix it or undo whatever 'fix' told the base template to stop displaying the field. No, the vast majority of users do not want to bother with memorizing ever shifting subsets of templates when there's a single underlying citation format we can use (and should be able to use) for everything. — LlywelynII 18:44, 5 January 2024 (UTC)

I can't confirm if any change has happened recently but would this not work:
* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |title=The Horoscope of the Foundation of Rome |journal=Classical Philology |volume=81 |number=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.
* Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81 (2), Chicago: University of Chicago Press: 148–153, JSTOR 269789.
As I understand it 'citation' dynamically formats depending on which fields you use. Contribution/Title cause it to beleive your cite is for a book rather than a journal. -- LCU ActivelyDisinterested «@» °∆t° 19:12, 5 January 2024 (UTC)

(edit conflict)asd

There is nothing new here. Here is how both of your examples actually render:

Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, vol. 81, Chicago: University of Chicago Press, pp. 148–153, JSTOR 269789

{{citation}} is and has been for a very long time sort of automatic in that it will render a correct citation if you, the editor, give it the correct parameters. Apparently, Classical Philology is a peer-reviewed academic journal. As such, when citing an article in that journal, it is incumbent upon you to tell {{citation}} that you are citing a journal by providing a value for |journal=. This is how {{citation}} knows to render |issue=. So, slight tweaks (|title= → |journal= and |contribution= → |title= gives this rendering:

{{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |title=The Horoscope of the Foundation of Rome |journal=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}

Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81 (2), Chicago: University of Chicago Press: 148–153, JSTOR 269789

Without |journal=, {{citation}} assumes that the source being cited is a book so renders the citation accordingly.

—Trappist the monk (talk) 19:16, 5 January 2024 (UTC)

But none of this is correct. It's a contribution to a work with a title and what is the possible benefit of suppressing the issue fields when they are provided? It's not a misapplied syntax. It's just a badly formatted template that previously worked and now doesn't because the word "title" is being misparsed as "book" for no apparent reason. It is something to fix, not something to lecture on. — LlywelynII 15:03, 28 January 2024 (UTC)

Shouting and moving this discussion to the bottom of this talk page does not bolster your argument. TLDR: nothing needs fixing; feel free to ignore the following 'lecture'.

In all of en.wiki, Grafton & Swerdlow's article "The Horoscope of the Foundation of Rome" from Classical Philology (journal) is mentioned in this discussion and in three other places (this search):

• Founding of Rome added at this edit 5 January 2024 by you
• Talk:Founding of Rome § Plutarch added at this edit 5 January 2024 by you
• Sulcus primigenius added at its creation 9 January 2024 by you

Your claim that the Grafton & Swerdlow template previously worked is incorrect. Here is that template as rendered by {{citation/old}}, the wikitext (pre-Lua module) version:

{{citation/old |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}

Grafton, A.T. et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81, Chicago: University of Chicago Press, JSTOR 269789 

For completeness, some history:

• We discussed limiting the use of |volume=, |issue=, |pages= in the cs1|2 templates at Help talk:Citation Style 1/Archive 10 § |volume=, |issue=, |page(s)= and cite magazine 18 November – 10 December 2015
• That discussion was implemented in the live cs1|2 module suite 5 December 2015.
• A table similar to the table in the above mentioned discussion, 'cs1|2 support for |volume=, |issue=, |page(s)=', was added to Help:Citation Style 1 § Pages at this edit 16 October 2016

There have been no recent changes that affect the suppression of |issue= in cs1|2 book citations (which includes {{citation}} without a periodical parameter).

—Trappist the monk (talk) 16:48, 28 January 2024 (UTC)

For journal articles, the OP might consider using {{cite journal}} with |mode=cs2 to achieve their desired output more easily. – Jonesey95 (talk) 01:47, 29 January 2024 (UTC)

OP would like a single template that works for all formats, which is what {{citation}} used to do, regardless of Trappist's claims. Title should handle all actual titles of complete works; contribution should handle all sectional titles within such works; and volumes and issues should display correctly when listed. OP specifically does not want to have to enter entirely separate templates for each separate form of work, which is needless bother.

All that needs to happen is that the code doesn't preemptively ignore the |issue= field. It's currently broken, easily fixed, and should be fixed. If it's been broken since 2015 without my noticing it, fine, but it's still needlessly broken and should still be corrected now. — LlywelynII 05:24, 3 February 2024 (UTC)

Here is a link to the very first version (permalink) of {{citation}} from 15 November 2005. {{{issue}}} (and its alias {{{number}}}) appear only where {{{journal}}} (and its alias {{{periodical}}}) appear. I can find no evidence that {{citation}} ever supported |issue= when the template did not include |journal= or other 'periodical' parameter.

Your claims to the contrary require evidence. So far all you have done is to make declarations about what {{citation}} used to do without supporting those declarations with evidence. Produce the evidence.

—Trappist the monk (talk) 14:52, 3 February 2024 (UTC)

You definitely used to be able to use {{citation}} and have |issue= when citing a book, not a journal. I’m not sure what “proof” would be but in 2017 I wrote (Help talk:Citation Style 1/Archive 37 § Example of book with journal-like properties, chapter authors and issue plus number indicators): Yeah I agree, it'd be nice to have issue number for books; right now a workaround is just to do {{citation|mode=cs1|...}}, which seems to allow more options. I remember not being able to use |issue= when a book has both a volume and issue associated with it, but for a time I could use {{citation}} to get around that limitation. And in 2019 (Help talk:Citation Style 1/Archive 58 § Books with volumes and parts) you acknowledged this workaround's existence saying Don't rely on that work-around remaining. It is a bug that should be fixed. Umimmak (talk) 05:26, 5 February 2024 (UTC)

Not shouting. Just highlighting the important bit in what's become a textwall post inside a textwall talk page. I get it that you're opposed and will either ignore me or revert changes if I implement them myself, since you seem to be the caretaker around here. (And thanks for that!) It's still important that this stand out for other posters when they come here for their own problems so they can add their +1 until you realize it's a template problem instead of a "rando schlub" problem and, y'know, actually fix it/allow it to be fixed. — LlywelynII 05:31, 3 February 2024 (UTC)

What you're shouting about has never existed as has been explained. {{citation}} has always auto-formated cites based on the fields it is supplied. If you don't supply the expected fields it won't format as you expect.
If you want something new maybe you should discuss the matter as a request for something new. -- LCU ActivelyDisinterested «@» °∆t° 16:51, 3 February 2024 (UTC)

This is not broken; it simply needs |journal= instead of |title=. If it were wanted to do something about this to make it more flexible and intuitive (without any arguments about "what used to happen" which can't be demonstrated and don't matter anyway), then clearly the thing to do would be to have |title= resolve to |work= ("the italicized thing"), any time both of these conditions apply simultaneously: 1) |chapter=, |contribution=, or any other alias for "the quotation-marked thing" is present with a value, and (not "or") 2) |work=, |journal=, |website=, or any other alias for "the italicized thing" is not also present with a value. This would actually have mutiple benefits. If something has both |chapter=, etc., and |journal=, etc., plus also a third thing in |title=, then that's an error and should be flagged as such, since there is no way to resolve it without human judgement.  — SMcCandlish ☏ ¢ 😼  03:18, 5 February 2024 (UTC)

Okay, I think this is where my technical expertise falls short, but I have been trying to export the Module:Citation/CS1 system to my own wiki. However, when I do, I get an error at https://nsindex.net/wiki/War, which states:

[6161720f6cfbf54ba3955ec6] /wiki/War MediaWiki\Storage\NameTableAccessException: Failed to access name from content_models using id = 4

The extensions and version info I am using are listed at: https://nsindex.net/wiki/Special:Version. I don't know changes I need to make to the modules, to make it work on an independent wiki. --Minoa (talk) 06:25, 3 February 2024 (UTC)

This appears to be a technical import issue that is outside the cs1|2 bailick. Having never done an import, I have only a passing knowledge of the process. Perhaps your best source of help is at WP:Village pump (technical). I would suggest that you describe, in full, the steps that you took that got you to where you are now. The cs1|2 module suite is routinely imported by other wikis so it would seem that the issue is in your particular wiki's setup.

—Trappist the monk (talk) 13:02, 3 February 2024 (UTC)

I would guess that you have misconfigured Scribunto or TemplateStyles or one of their dependencies, or lacking one of the latter (I note that you do not have LuaSandbox installed). Either way, this error is an issue for normal MediaWiki support channels like #mediawiki on mw:IRC or mw:Support. Izno (talk) 19:39, 3 February 2024 (UTC)

I'm sorry about choosing the wrong section. It's not like I am an expert at the nuts and bolts of MediaWiki and I had to rebuild the database since it appeared to be a database issue that caused the CS1 module to crash, thankfully I backed up everything but it's still annoying and frightening when an unforeseen error like that suddenly occurs. --Minoa (talk) 20:14, 3 February 2024 (UTC)

|location=Honolulu, Hawai{{okina}}i adds the article to Category:CS1 maint: location and |location=Honolulu, Hawaiʻi does not. There is ~6,000 articles in the category.

I have obviously figured out a workaround. Personally, I think both forms should work. Also, this is probably one example of problems using character templates in location parameter values.

Is there a consensus solution for resolving this situation? Thanks in advance. User-duck (talk) 10:22, 4 February 2024 (UTC)

Fix {{okina}}? The category addition occurs because {{okina}} uses the html numeric entity ʻ. What cs1|2 sees is Honolulu, Hawaiʻi.

The related templates, {{'eta}} and {{fakau'a}} use the unicode characters U+02BC ʼ MODIFIER LETTER APOSTROPHE and U+02BB ʻ MODIFIER LETTER TURNED COMMA. This is the 21st century, I see no reason why {{okina}} can't use U+02BB ʻ MODIFIER LETTER TURNED COMMA instead of ʻ.

—Trappist the monk (talk) 13:15, 4 February 2024 (UTC)

Fixed [11]. We'll see if it sticks.  — SMcCandlish ☏ ¢ 😼  03:00, 5 February 2024 (UTC)

Right now the only way to include separate conference-related metadata about a conference paper (conference name, dates, location) is to use the {{cite conference}} template. This leaves pages otherwise using {{citation}} needing to use {{cite conference |mode=cs2 |conference=...}}. Instead of doing this, many pages using CS2 style just leave off the conference metadata entirely, or arbitrarily mash it into the existing parameters, e.g. using the publication location parameter to hold the conference location, even when the conference proceedings were published somewhere else, or using the title parameter to hold the conference name even when the published proceedings are titled differently.

Would it be possible to add conference=... (or some more generic free-form field that could be used for the same purpose) to the {{citation}} template, so we could write e.g. {{citation |conference=...}}? –jacobolus (t) 22:54, 5 February 2024 (UTC)

Regarding: Template:Citation Style documentation/url

Firstly, this is not an issue for me, I just happened to be reading this section and wondered about this. But hopefully a clarification could be helpful for others in the future.

Under url-status, it says the values unfit or usurped are used when the URL/domain links to "vice", but it's not clear what that means. Is there a help page that could be linked there to clarify?

For me, when I hear "vice", I think, say, gambling, drugs, and pornography, but I'm not sure that's what it's referring to. (Funny enough, the reason I was reading this section was regarding a link to a liquor company, which could be considered "vice" under some definitions.)

An obvious case is a URL that used to point to a news article but now points to pornography; obviously we shouldn't keep that link to avoid any unpleasant surprises for people clicking the "original link", but I can imagine more complicated cases.

By the way, in the same section, I believe "reseller" refers to domain resellers specifically. That should maybe be clarified too.

— W.andrea (talk) 20:41, 3 February 2024 (UTC)

@W.andrea: I think that in this context "vice" does include gambling and pornography, as those are two common types of content we are redirected to when a web domain is no longer live. GoingBatty (talk) 21:55, 3 February 2024 (UTC)

I've boldly modified unfit and usurped in the doc; feel free to revert or edit. Actual change to guideline rather than just wording; the distinction between unfit and usurped wasn't clear (and they actually do exactly the same). Quicker to do it and if necessary revert than long discussion. Best wishes, Pol098 (talk) 23:55, 3 February 2024 (UTC)

Is vice not clear? It's just a 1 word label instead of having to write out "pornography, gambling, etc.." every time in the document. If the word vice is curious ("what does vice mean?"), then we can make a footnote listing some examples.

Secondly, the change made by Pol098 is not what we have agreed on. There is a difference between an entire domain being usurped. And individual URLs within a domain being inappropriate, but otherwise not usurped. For example, a news aggregator site might have lots of safe URLs. But one of its stories contains blatant pornography or gambling spam. So we individually suppress URLs from legitimate domains using |unfit=. Or we can suppress an entire domain that has been usurped. In effect both of these do the same thing, but they are operating at different levels and mean something different. In brief: usurpation occurs at the domain level. Unfit at the page level. -- GreenC 01:36, 4 February 2024 (UTC)

Is vice not clear? Vice is a culturally informed topic with differing interpretations; one prominent example is the Committee for the Promotion of Virtue and the Prevention of Vice. Another example is that my grandfather considers it a vice to go shopping on Sunday, but I do not. Please consider another word if brevity is the concern here. Orange Suede Sofa (talk) 03:16, 5 February 2024 (UTC)

Because this is yet another discussion about this topic, I'm beginning to wonder if we wouldn't be better off defining unfit and usurped as equal aliases. Editors can then choose the one that seems best to them. That might remove the apparent need to quibble over the individual meanings of the keywords. If we do that then, the definition might be rewritten like this:

• unfit or usurped – selects |archive-url=; used when |url= links to vice (gambling, pornography), advertising, a domain reseller or other unsuitable page; links to |url= are suppressed in the rendering. If an entire domain is unsuitable, consider instead usurpation or blacklist.

—Trappist the monk (talk) 01:56, 4 February 2024 (UTC)

The question still exists, when is it appropriate to use the word "unfit" vs "usurped". We can provide guidance as noted, the difference is between an entire domain being a problem, versus a page being a problem within an otherwise fine domain. -- GreenC 02:35, 4 February 2024 (UTC)

"the difference is between an entire domain being a problem, versus a page being a problem" - great, that makes sense, but the documentation needs to make that clear. Very much a storm in a teacup, the distinction has no effect on the reader, and the editor can see where the page now links. My edit doesn't make this point, but it doesn't make the guideline worse so I won't withdraw it, and hope it will be improved upon. Even the name is vague, unfit-page, usurped-domain is better. Best wishes, Pol098 (talk) 12:04, 4 February 2024 (UTC)

I thought the documentation does make that clear? One says page, the other says domain. -- GreenC 17:41, 4 February 2024 (UTC)

Agree with merging them and making one an alias of the other. They don't do anything distinct, and it's silly to argue about a distinction that doesn't matter for any practical purpose. Something that does matter would be to shop generating a warning message when these parameters are used. What good is it if it's interpreted as if an error? If I used that parameter, I did so on purpose, and I don't need a pseudo-warning to try to convince me something is broken every time I edit the page. Just inspires someone else later to think it is broke and mess with it.  — SMcCandlish ☏ ¢ 😼  03:03, 5 February 2024 (UTC)

Do these do the same thing? I can't tell any difference when using them, from the maintenance category, or from the sandbox. Agree that it make sense for them to be aliases. Can we go ahead and present them as aliases in the documentation now? Rjjⁱⁱⁱ (talk) 16:27, 14 February 2024 (UTC)

Hi, @TechnoSquirrel69 reported this bug on Phabricator, but it seems to be a problem with the templates. Please see https://phabricator.wikimedia.org/T356831 for screenshots.

Steps to replicate the issue (include links if applicable):

• Open this permalink. Any page that uses the access icons could also have this issue. Here's another.

What happens?:

• See that the icons are getting clipped on the top, bottom, or both.

Other information (browser name/version, screenshots, etc.):

• I'm getting this issue on Firefox and Chrome. It seemed to turn up most reliably on Monobook, sometimes on Vector 2010, but neither of them had a 100% reproducibility rate.

Matma Rex talk 12:27, 7 February 2024 (UTC)

The size of the access icons was chosen to fit the font size that readers see with the default skin (at the time, that was Vector – since renamed as Vector legacy 2010). It appears that the Monobook skin has a smaller default font size (not in MediaWiki:Monobook.css so I don't know where the Monobook default font size is set). The issue is exacerbated by use of {{reflist}} and {{ref begin}} which render references at 90% of Monobook's already smaller default font size.

sometimes on Vector 2010 Examples of where you see this? I use Vector 2010 and have never noticed clipped access icons.

I'm not inclined to do anything about this. So long as the access icons display correctly for our readers, I see no reason to expend the time and effort for those relative few editors who use Monobook. Is it even possible for us to know the skin that a reader is using? I suppose that some Monobook css can include overrides for the access-icon css in Module:Citation/CS1/styles.css. I notice that Monobook uses PDF icons that are different from those used in Vector 2010 so wherever the Monobook PDF icon is defined might be an appropriate place to override the cs1|2 access-icon css. Doing that is outside the cs1|2 bailiwick and will no doubt require the services of an interface administrator.

—Trappist the monk (talk) 16:31, 7 February 2024 (UTC)

Did you know that TemplateStyles selectors can begin with something like body.skin-monobook? Also, did you know that a contain keyword exists for the CSS background-size property? Either of those could potentially be used to resolve this. Anomie⚔ 12:38, 8 February 2024 (UTC)

I did not. I did not. Thank you for that; I have little knowledge and experience with css. I used both in Module:Citation/CS1/sandbox/styles.css. Here are permalinks to my sandbox using the various skins:

• minerva
• monobook
• timeless
• vector
• vector 2022

Anyone know how to get rid of the duplicate warnings like this one:

Warning: Background image '//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg' was used multiple times, first declared at line 51, col 2.

There are four such warnings: line 57, line 79, line 95, and line 112.

—Trappist the monk (talk) 16:19, 8 February 2024 (UTC) 18:09, 8 February 2024 (UTC)

Found a solution.

—Trappist the monk (talk) 18:09, 8 February 2024 (UTC)

For example in this book Following the Equator, there are two different publisher company credited in two different place.

While using this Template:Cite book however, there are only publisher= and place= parameter for one value despite there are two values. Therefore, for now it coded like this: " |publisher=American Publishing Co. and Doubleday & McLure Co. |place=Hartford and New York ",

and displayed like this: " Hartford and New York: American Publishing Co. and Doubleday & McLure Co. ",

where it should have displayed like this: " Hartford: American Publishing Co., and New York: Doubleday & McLure Co. "
EdhyRa (talk) 12:09, 10 February 2024 (UTC)

This should be similar to various ID parameters like doi. See Nubian ibex for a citation with this parameter. "hal=hal-00888596" or "hal=00888596" (implementer's choice) should link to https://hal.science/hal-00888596 - UtherSRG (talk) 15:23, 11 February 2024 (UTC)

You can use the {{HAL}} template and the |id= field to achieve this, see my edit[12] to Nubian ibex. -- LCU ActivelyDisinterested «@» °∆t° 16:05, 11 February 2024 (UTC)

There's usually a re-existing template you can use, {{BNF}} for links to Bibliothèque nationale de France for instance. -- LCU ActivelyDisinterested «@» °∆t° 16:06, 11 February 2024 (UTC)

Hrm. Ok. But I was hoping, after a doi-like implementation, that I could then poke on User:Citation bot's maintainer AManWithNoPlan to scrape for additional data. Is that possible with "id="? - UtherSRG (talk) 16:15, 11 February 2024 (UTC)

Sorry that's something you'd need to ask AManWithNoPlan. -- LCU ActivelyDisinterested «@» °∆t° 17:35, 11 February 2024 (UTC)

{{HAL}} is used in only ten articles right now. That's not enough to add a whole new parameter, with all of the support that entails. Putting the template in |id= is usually what we recommend until usage reaches a higher level (vague mumbling about what constitutes a "higher level"...). – Jonesey95 (talk) 18:24, 11 February 2024 (UTC)

Yay for vague mumblings! XD - UtherSRG (talk) 20:37, 11 February 2024 (UTC)

There is a section WP:COSMETICBOT that explains differences between a cosmetic change or a substantive change. Does fixing a "cs1 error" or a "cs1 maintenance" issue constitute a cosmetic change or a substantive change?

There are pages in the "CS1 errors" and "CS1 maintenance" category:

• https://en.wikipedia.org/wiki/Category:CS1_errors
• https://en.wikipedia.org/wiki/Category:CS1_maintenance

There are multiple subcategories of CS1 errors and CS1 maintenance. From the first sight, some of which look like cosmetic, while other look like substantive.

It is explained in the WP:COSMETICBOT that a substantial change is considered the "administration of the encyclopedia", such as the maintenance of hidden categories used to track maintenance backlogs (e.g. changing "citation needed" to "citation needed|date=September 2016").

If there is no general answer on whether "CS1 errors" and "CS1 maintenance" categories are cosmetic or substantive:

• "CS1 maint: PMC format",
• "CS1 errors: access-date without URL",
• "CS1 errors: archive-url"?

Maxim Masiutin (talk) 20:06, 11 February 2024 (UTC)

It is technically a substantive change, since it removes a category, and often an error or maintenance message, from the rendered page. – Jonesey95 (talk) 23:04, 11 February 2024 (UTC)

Why doesn't |orig-date= format its output IAW the article's implementation of {{use dmy dates}} or {{use mdy dates}} (like |date= does)? — Fourthords | =Λ= | 20:08, 11 February 2024 (UTC)

Because the assigned value is not constrained to date-only.

—Trappist the monk (talk) 20:30, 11 February 2024 (UTC)

Question for the citation team: Is there a reason cite thesis doesn't have a page/pages field? I know we're not supposed to cite anything below a Ph.D. thesis (a rule that I may or may not selectively ignore but never mind) but is it wrong to include thesis page numbers for some reason? I am not a professional academic so this might be a known thing with theses or bibliographies. (Shorter: I'm asking out of ignorance/curiosity/good faith.) I usually just tack them between the ref tags after the cite thesis template but I always get the distinct feeling I'm doing something wrong. Thank you in advance for guidance. jengod (talk) 22:20, 14 February 2024 (UTC)

It does. Are you using the VisualEditor? We probably need to fill out the TemplateData. The TemplateData for {{cite book}} and {{citation}} are much more complete. The parameters unique or specific to {{cite thesis}} could be added to one of those and then the unsupported parameters can be removed. Regards, Rjjiii (ii) (talk) 22:43, 14 February 2024 (UTC)

I am so sorry to be a difficult patient but I have no idea what I use to edit other than "my phone" and I toggle back and forth between desktop and en.m as needed. When I add a page to a cite thesis template and then use the little citations gizmo it tells me "unsupported parameter." See image. "unsupported parameter" seems like it might make the robots mad and I want to be supportive of our robot buddies. But you're saying I can ignore? jengod (talk) 23:13, 14 February 2024 (UTC)

@Jengod: It's all good. That's the VisualEditor (Wikipedia:VisualEditor). You can ignore that message beside "page". "undocumented parameter" is meant literally. It is supported by the template but not documented. If you scroll down to the bottom of any template's documentation page, you will probably see a big table of parameters or a link to a page with a big table of parameters. Those tables are the JSON data that the VisualEditor uses. It's called Wikipedia:TemplateData, and many less-used templates lack it completely. It honestly seems like a pretty weird system. I have just added the parameters from {{Citation}} that cover page, pages, at, no-pp, and chapter. Rjjⁱⁱⁱ (talk) 00:11, 15 February 2024 (UTC)

@Rjjiii awesome. I've been double-taking at that for a while now. Thanks for the fix. Much appreciated. best, jengod (talk) 00:15, 15 February 2024 (UTC)

Could we clarify the meaning of the description for |language= in the CS1/2 TemplateData section? The current text states The language in which the source is written, if not English; use a two-letter language code or the full language name, which could be interpreted in one of two ways. Either it is a description of the output of the parameter, where if the parameter is |language=en it will not be displayed in the text delivered to the reader of an article, or as one user recently said to me it is an instruction not to use |language=en for citations to English language articles. My understanding of the longstanding consensus is that we include the |language=en to make it easier for non-English language wikis to directly use our citations when translating our articles.

Additionally, the interpretation that the TemplateData entry is an instruction doesn't seem to match with the template documentation's usage section. The usage section states that When the only source language is English, no language is displayed in the citation, however it does not recommend against using |language=en when it is appropriate per the cited source. If the consensus is that we should still include |language=en for English language citations, could we update the text in the TemplateData section to make it less ambiguous? Or if the consensus has changed, and that we shouldn't use |language=en could we update the usage section text to make that more explicit? Sideswipe9th (talk) 00:31, 15 February 2024 (UTC)

English

IMHO, language=en and en-gb or en-nz or en-pk is harmless and/or is often automatically pulled from whatever bibliographic database you're using and the path of least resistance is to leave it. I personally like it, it adds nice detail to citations, and this is a vast international project and the same way we use regional English language templates (e.g. {{use Sri Lankan English}}), in part as a gesture of inclusivity and respect, I think acknowledging regional variations is appropriate and certainly not wrong. My layperson's understanding is that maxing out metadata is central to excellent information systems management, which is what we do.

not!English

If your source is not in English, include the appropriate language code, and where appropriate include regional variation codes where they exist, for example I believe Flemish is nl-be (Dutch, but in Belgium!), Brazilian Portuguese is pt-br, Mexican Spanish is es-mx, etc. The languages are probably very similar, if not identical, especially "in print", but the most descriptive possible tagging is beneficial and again it's a respectful gesture that acknowledges linguistic and cultural diversity.

jengod (talk) 00:55, 15 February 2024 (UTC)

{{Cite journal | first=Deborah Dash | last=Moore | title=none | department=Review of Daniel Morris, ''After Weegee: Essays on Contemporary Jewish American Photographers'' (Syracuse: Syracuse University Press, 2011) | work=American Jewish History | volume=97 | number=1 | date=March 2013 | pages=93–94 | doi=10.1353/ajh.2011.0012}}

unfortunately (for my purpose) renders

Moore, Deborah Dash (March 2013). "none". Review of Daniel Morris, After Weegee: Essays on Contemporary Jewish American Photographers (Syracuse: Syracuse University Press, 2011). American Jewish History. 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

with an unwanted title of "none". How does one do away with titles?

(Additionally, "Review of Daniel Morris, After Weegee [blah blah]" is hardly a "department". The department might well be "Book reviews" [plural], though I haven't looked. A superior alternative replacement for "department" would be welcome.)

I'm pretty sure that this is a question I asked, and that was expertly answered, a few months ago. Sorry! (I did look for the older Q&A, but couldn't find it.) -- Hoary (talk) 05:29, 15 February 2024 (UTC)

Brackets "untitled" - I wish it supported "[no title]" to be consistent with n.a. for no author, n.d. for no date, and no pag. for "no pagination" but close enough!

Moore, Deborah Dash (March 2013). "[untitled]". Review of Daniel Morris, After Weegee: Essays on Contemporary Jewish American Photographers (Syracuse: Syracuse University Press, 2011). American Jewish History. 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

jengod (talk) 06:16, 15 February 2024 (UTC)

In this case I think you're good to put mostly any "title not original the source" in brackets and slot it into the title slot. The brackets indicate it's created by the cataloger or bibliographer and not what the original author named their artwork.

Moore, Deborah Dash (March 2013). "[Review of Daniel Morris, After Weegee: Essays on Contemporary Jewish American Photographers (Syracuse: Syracuse University Press, 2011)]". Reviews. American Jewish History. 97 (1): 93–94. doi:10.1353/ajh.2011.0012. jengod (talk) 06:23, 15 February 2024 (UTC)

jengod, thank you, that's definitely an improvement. But I remember, or misremember, that there's an even neater fix. -- Hoary (talk) 07:27, 15 February 2024 (UTC)

I believe you and I'm over here with my popcorn. I love all these cite templates--they have so many cool secrets and nooks and crannies! jengod (talk) 07:34, 15 February 2024 (UTC)

Your citation shows "none" because you used |work=American Jewish History when you should have named the journal as a journal: |journal=American Jewish History:

{{Cite journal |first=Deborah Dash |last=Moore |title=none |department=Review of Daniel Morris, ''After Weegee: Essays on Contemporary Jewish American Photographers'' (Syracuse: Syracuse University Press, 2011) |journal=American Jewish History |volume=97 |number=1 |date=March 2013 |pages=93–94 |doi=10.1353/ajh.2011.0012}}

Moore, Deborah Dash (March 2013). Review of Daniel Morris, After Weegee: Essays on Contemporary Jewish American Photographers (Syracuse: Syracuse University Press, 2011). American Jewish History. 97 (1): 93–94. doi:10.1353/ajh.2011.0012.{{cite journal}}: CS1 maint: untitled periodical (link)

Do not misuse cs1|2 parameters (|department= in place of |title= etc). Consider writing the review title as the title is written on the journal page and specify |type=Review. Omit the more-or-less unnecessary bibliographic detail for the avoidance of confusion (sometimes such titles contain ISBN identifiers, price, physical dimensions... that are not relevant when citing the review):

{{Cite journal |first=Deborah Dash |last=Moore |title=''After Weegee: Essays on Contemporary Jewish American Photographers''. By Daniel Morris |type=Review |journal=American Jewish History |volume=97 |number=1 |date=March 2013 |pages=93–94 |doi=10.1353/ajh.2011.0012}}

Moore, Deborah Dash (March 2013). "After Weegee: Essays on Contemporary Jewish American Photographers. By Daniel Morris". American Jewish History (Review). 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

—Trappist the monk (talk) 14:54, 15 February 2024 (UTC)

Is there a way to get "type" (or a similar parameter) to render after the contribution title instead of after the journal name? This would be clearer if it said:

Moore, Deborah Dash (2013). "After Weegee: Essays on Contemporary Jewish American Photographers, by Daniel Morris" (Book review). American Jewish History. 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

–jacobolus (t) 19:59, 15 February 2024 (UTC)

Related: it would be very helpful if "language" could attach to just the contribution name instead of the journal name. For example, many old math journals routinely included a mix of papers in English, French, German, etc., which make it confusing to have a citation like Last, First (1850). "Title in German" [English translation]. French Journal Name (in German). 4 (5): 72–90. Indeed arguably the "language" and possibly "type" parameter should always attach to the chapter/contribution name, rather than the book/journal name. –jacobolus (t) 21:04, 15 February 2024 (UTC)

For book reviews, "Consider writing the review title as the title is written on the journal page" is very bad advice. That leads to titles like "Siobhan Roberts.King of Infinite Space: Donald Coxeter, the Man Who Saved Geometry. xv + 399 pp., illus., figs., apps., bibl., index. New York: Walker & Company, 2006. $27.95 (cloth)." Nobody sane wants that. —David Eppstein (talk) 20:45, 15 February 2024 (UTC)

Or in this case, "After Weegee: Essays on Contemporary Jewish American Photographers. By Daniel Morris. Syracuse: Syracuse University Press, 2011. xxxvi + 299." But I think the idea would be to cut to just the book title + author, not including publisher, ISBN, price, page count, etc. The purpose of the citation is to identify the source [here the review], not dump a pile of unnecessary noise on the reader. Personally I sometimes shorten long book titles in such citations to just the first part, along the lines of just:

Moore, Deborah Dash (2013). "After Weegee, by Daniel Morris". American Jewish History (Book review). 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

But it would be clearer still if "type" was attached to the review title rather than the journal name. –jacobolus (t) 20:54, 15 February 2024 (UTC)

Pretty obvious that you failed to read all that I wrote. Let me give it to you again:

Consider writing the review title as the title is written on the journal page and specify |type=Review. Omit the more-or-less unnecessary bibliographic detail for the avoidance of confusion (sometimes such titles contain ISBN identifiers, price, physical dimensions... that are not relevant when citing the review)

—Trappist the monk (talk) 22:47, 15 February 2024 (UTC)

Good morning (where I am); and thank you, all. I'll follow the monk's suggestion. Of course the template's semantics are important but I'm also fairly happy with the appearance. However, I second jacobolus' request/suggestion that the value (here, "review") of the "type" attribute is appended not to the journal title but instead to the title [if it even is a title] of the piece that's being cited. ¶ Though [opens can of worms] actually I'd prefer output such as

Deborah Dash Moore (2013). Review of After Weegee, by Daniel Morris. American Jewish History 97 (1): 93–94. doi:10.1353/ajh.2011.0012.

(with no quotation marks around what I think is a description rather than a title; and no inversion of the order of the author's name, as it's not within an alphabetically ordered list of surnames). But I imagine that such proposals have already been suggested, discussed, and rejected. -- Hoary (talk) 23:46, 15 February 2024 (UTC)

(If you feel strongly about a particular citation, you can always use plain wiki-markup instead of a template. If you need to link to it from shortened footnotes use {{wikicite}}.) –jacobolus (t) 23:49, 15 February 2024 (UTC)

jacobolus, yes, I know. For a long time I didn't use cite templates (other than when working on articles that already used them), because they seemed not to cater for a lot of bibliographic peculiarities that I'd often encounter -- notably books with two or more parallel texts (perhaps one in Dutch and one in French) and thus two or more titles. An enormous amount of work has gone into the templates and I understand the value of using them (for machine-parsability, etc). I use them, but I still have niggles (as is to be expected for any complex system). Anyway, I've gratefully implemented the suggestion above. -- Hoary (talk) 01:44, 16 February 2024 (UTC)

Wikipedia:Village_pump_(miscellaneous)#Data_Citation_Corpus -- GreenC 15:03, 16 February 2024 (UTC)

Lybarger, Donald F., ed. (August 1942). "Angier House (1854–1866), Kennard House (1866–c. 1940); Lincoln Hotel (1940—)". Historic Sites of Cleveland: Hotels and Taverns (Report). Columbus: Ohio Historical Records Survey Project. pp. 366–437 – via Ohio Works Progress Administration Publications, University of Kentucky Libraries Special Collections.  This article incorporates text from this source, which is in the public domain.

{{cite report |title=Historic Sites of Cleveland: Hotels and Taverns |location=Columbus |publisher=Ohio Historical Records Survey Project |editor-last=Lybarger |editor-first=Donald F. |date=August 1942 |pages=366–437 |chapter=Angier House (1854–1866), Kennard House (1866–{{circa|1940}}); Lincoln Hotel (1940—) |author-link=Historical Records Survey |url=https://exploreuk.uky.edu/catalog/xt7vt43j1895 |ref={{harvid|Historical Records Survey|1942}} |via=Ohio Works Progress Administration Publications, University of Kentucky Libraries Special Collections}} {{PD-inline}}

So. This is a fairly obscure government report. The only place it's online is this university library. As part of wikiloving our friends the librarians and archivists, I like to include as much "repository" credit as I can jam into citations. If it was just an inaccessible box I would use {{cite archive}} but I think it's appropriate to treat this as a book/report/website etc.

Anyway, I would've loved to steal the institution= and collection= attributes from {{cite archive}} for this ref, except it says that publisher and institution can't be used simultaneously, and collection is not a supported attribute. *So* via= is doing a fine job handling this task, but I would love if there were archive attributes like repository= and/or collection= attribute in the main cite template.

Another example where I would have used this is on Chicano Liberation Front. I think I emailed three libraries before someone had a copy of this obscure local underground paper; once I found it they were so cool and scanned it and sent it right over. So definitely wanted to give credit. But the citation for the *article* doesn't really accommodate the additional archival detail that sometimes I would like to include.

Blake, Michael (1971-08-13). "Barrio Bombers Speak Out: Walking softly in the barrio with a big stick...of dynamite (Communique from Chicano Liberation Front)". Los Angeles Free Press. Vol. 8, no. 33. pp. 1–2. ISSN 0024-6573. Issue 369 – via Center for Southwest Research at University of New Mexico - Underground Newspaper Collection, MSS 514 BC, Box 48.

{{Cite news |last=Blake |first=Michael |date=1971-08-13 |title=Barrio Bombers Speak Out: Walking softly in the barrio with a big stick...of dynamite (Communique from Chicano Liberation Front) |volume=8 |pages=1–2 |work=[[Los Angeles Free Press]] |issue=33 |issn=0024-6573 |id=Issue 369 |via=Center for Southwest Research at [[University of New Mexico]] - Underground Newspaper Collection, MSS 514 BC, Box 48}}

To make a long story long, in a perfect world designed around me me me (LOL), the "main" cite template would also allow more "physical location" attributes like are included in cite archive, like so:

{{Cite news |last=Blake |first=Michael |date=1971-08-13 |title=Barrio Bombers Speak Out: Walking softly in the barrio with a big stick...of dynamite (Communique from Chicano Liberation Front) |volume=8 |pages=1–2 |work=[[Los Angeles Free Press]] |issue=33 |issn=0024-6573 |id=Issue 369 |repository=Center for Southwest Research |institution=University of New Mexico |location=Albuquerque, N.M. |collection=Underground Newspaper Collection |series=MSS 514 BC |box=48 |collection-url=https://nmarchives.unm.edu/repositories/22/archival_objects/196279 }}

I guess another way to do it would be to have a {{cite book}} and a {{cite archive}} side by side within the ref tags, but that might...break something?

I'm probably writing this all out as procrastination from the transcription I need to do for this Kennard House draft but I wanted to float this idea and see if anyone else had asked about this before or if there were any recommended workarounds. THANK YOU! jengod (talk) 06:29, 18 February 2024 (UTC)

jengod, See {{Cite archive}}. Param |via= is definitely not the place for it. Mathglot (talk) 06:52, 18 February 2024 (UTC)

@mathglot so could I do {{cite book}} and {{cite archive}} side by side in one ref? jengod (talk) 16:35, 18 February 2024 (UTC)

OK I tried it, linked by the word "at". So far so good. Thank you!! jengod (talk) 19:53, 18 February 2024 (UTC)

In this discussion (permalink) an editor asked: Is there a way to get "type" (or a similar parameter) to render after the contribution title instead of after the journal name?

That question got me wondering about cleaning up the mess that is tcommon assignment. tcommon is an internal variable in Module:Citation/CS1 that is used when assembling a cs1|2 citation rendering. For example, the tcommon assignment for the standard {{cite book}} template looks like this:

tcommon = safe_join( {Title, TitleNote, Conference, Periodical, Format, TitleType, Series, Language, Volume, Others, Edition, Publisher, Agency}, sepc );

where Title, TitleNote, Conference, etc are metaparameters associated with |title=, |department= (or |title-note=), |conference= etc. – this is how cs1|2 deals with aliases.

In the above assignment, Conference, Periodical, and probably Agency do not apply to book citations so there is no real reason for those metaparameters to be in the tcommon assignment.

Since I am thinking about these assignments, now would be a good time to revisit parameter positioning in the citation renderings. I guess my gut feel is that |type= should not be moved closer to |title= in journal citations but I suppose that I might be convinced otherwise. Are there other parameters that ought to be repositioned?

Current live-module renderings can be seen in my sandbox (permalink).

—Trappist the monk (talk) 18:41, 18 February 2024 (UTC)

In {{cite map}}, a map that is a stand-alone document has its title rendered in italics, using |title= to hold that title. That title is then followed by the "(Map)" type. If the map is contained within another work, such as citing a map within an atlas, the title of the map is held in |map=, rendered in quotation marks and has the type following it. To wit:

• Bureau of Public Roads; American Association of State Highway Officials (November 11, 1926). United States System of Highways Adopted for Uniform Marking by the American Association of State Highway Officials (Map). 1:7,000,000. Washington, DC: United States Geological Survey. OCLC 32889555.
• Rand McNally (2023). "Michigan" (Map). The Road Atlas 2024: United States, Canada Mexico (100th Anniversary Special Collector's ed.). c. 1:1,267,200. Chicago: Rand McNally. pp. 50–51. § Q9. ISBN 978-0-528-02718-5.

Having that type indication shift positions like that makes sense to me. The atlas isn't the map, the map within it is the map. In another context, take a look at:

• "Road Shift with State Well-Planned". The Mining Journal (Editorial). Marquette, Michigan. April 27, 2005. p. A6. ISSN 0898-4964.

The implication there is that the newspaper itself is the editorial, as the type in parentheses is qualifying or describing the paper instead of describing the cited content within. If instead it renders as:

• "Road Shift with State Well-Planned" (Editorial). The Mining Journal. Marquette, Michigan. April 27, 2005. p. A6. ISSN 0898-4964

then we'd be clearing stating that the article cited is an editorial. The same could be said for any number of common descriptors of journal articles. Imzadi 1979 → 06:36, 19 February 2024 (UTC)

Hello! As part of this discussion, can we move source generation to a separate page and break it down into types/variants? To make it easier to edit the sources display in other wiki projects? Iniquity (talk) 12:24, 19 February 2024 (UTC)

I don't understand what it is that you are asking. cs1|2 doesn't do source generation whatever that is.

—Trappist the monk (talk) 14:03, 19 February 2024 (UTC)

I'm mostly talking about the code that starts at line 3951. We talked to you a few months ago that it would be cool to be able to customize the display of sources to local standarts. You advised to use local templates, but it seems to me that this does not make sense since this module provides too many useful functions. Iniquity (talk) 15:04, 19 February 2024 (UTC)

Help talk:Citation Style 1/Archive 91 § Another render of the source template? That is outside of the scope of this discussion but briefly, the code beginning at line 3951 is only part of the final rendering. If I understand what it is that you are asking, we must scour the code for anything that does any part of the rendering and somehow move those pieces to a new submodule without breaking the current renderings. If you want to discuss that, start a new discussion.

—Trappist the monk (talk) 15:31, 19 February 2024 (UTC)

Ok, thanks! :) Iniquity (talk) 20:47, 19 February 2024 (UTC)

I have removed Conference, Periodical, and Agency metaparameters from the book and journal tcommon assignments. I have also removed Format from all tcommon assignments because by the time execution reaches that point, Format (if it had been set) has been unset to empty string so inserting an empty string in the tcommon assignment is pointless.

I wonder about how {{cite journal}} handles |others=. When the author and editor name-lists are empty, |others= is the first element of the rendered citation; when either or both author and editor name-list present, they immediately precede |others=:

{{cite journal |author=Author-name-list |editor=Editor-name-list |others=Other-name-list |title=Title |journal=Journal}}

Author-name-list. Editor-name-list (ed.). "Title". Journal. Other-name-list. {{cite journal}}: |author= has generic name (help)

{{cite journal |others=Other-name-list |title=Title |journal=Journal}}

"Title". Journal. Other-name-list.{{cite journal}}: CS1 maint: others (link)

Compare to {{cite magazine}}:

{{cite magazine |author=Author-name-list |editor=Editor-name-list |others=Other-name-list |title=Title |magazine=Magazine}}

Author-name-list. Editor-name-list (ed.). "Title". Magazine. Other-name-list. {{cite magazine}}: |author= has generic name (help)

{{cite magazine |others=Other-name-list |title=Title |magazine=Magazine}}

"Title". Magazine. Other-name-list.{{cite magazine}}: CS1 maint: others (link)

For consistency it seems to me that {{cite journal}} should render |others= in the same way as all other cs1 templates (same as {{cite magazine}}).

—Trappist the monk (talk) 19:54, 19 February 2024 (UTC)

In footnote #3: https://en.wikipedia.org/w/index.php?title=Asin_Road&oldid=1175617230

There is a date mismatch between the archive URL and archive-date - the error was not being displayed or reported in the tracking category. I fixed the timestamp Special:Diff/1207477051/1208956488 and then it was reported: https://en.wikipedia.org/w/index.php?title=Asin_Road&oldid=1208956488

This variation of timestamp for archive.today was in about 4,000 articles, and there were date mistmatch errors in about 100 of them not showing up in the tracking category. It should be cleaned up for now on enwiki, but likely exists in higher volume on other wikis. This variation is copy-pasted by users because archive.today uses it when clicking the "share" button. -- GreenC 19:45, 19 February 2024 (UTC)

Fixed in sandbox:

—Trappist the monk (talk) 20:30, 19 February 2024 (UTC)