Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

article numbers

There was a discussion at User talk:Citation bot/Archive 33 § Pages vs Issue vs at vs ... about what to do with journal articles that are numbered. Because we don't have an article number-specific parameter, I suggested using |number= and was immediately shot down by those who apparently believe that article numbers belong in the in-source parameters |pages=, |pages=, or |at=. I believe that that is incorrect because doing so corrupts the metadata if the cite requires pagination. Sure, my |number= suggestion suffers from the same fault.

So, since COinS supports article numbers with the &rft.artnum= k/v pair which has heretofore been unused by cs1|2, I have hacked the module sandboxen to support new |article-number= in {{cite journal}} only:

{{cite journal/new |title=Title |journal=Journal |volume=XIV |article-number=56 |page=15}}

"Title". Journal. XIV 56: 15.

'"`UNIQ--templatestyles-00000025-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. <b>XIV</b> 56: 15.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.volume=XIV&rft.artnum=56&rft.pages=15&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

If we are to keep this we should decide some things:

• how are article numbers to be annotated or punctuated?
• are article numbers supported when both |volume= and |issue= are set? yes
• do article numbers require |volume=?

Beyond those things, if we are to keep this, support for journal cites using {{citation}} should be supported ({{cite journal}} with |mode=cs2 is of course already supported)

Keep? Discard?

—Trappist the monk (talk) 21:51, 10 September 2022 (UTC) 14:37, 11 September 2022 (UTC)

This is useful only regarding a few online journals that don't bother with journal pagination at all and those that paginate each numbered article at p. 1. Others have both article numbers and journal-level pagination, and citing both is superfluous. |article-number= should be a global alias of |pages=. The article/column title which is the actual in-source location is the primary discovery parameter (after journal-name, author etc). Parameters such as pages, article-numbers etc. are not in-source locations. From the reader's standpoint are ancillary helpers. 64.18.11.66 (talk) 00:15, 11 September 2022 (UTC)

If we are to believe our own documentation, for the purposes of cs1|2, |page=, |pages=, and |at= are in-source locators; see Template:Cite journal § In-source locations as an example, others are similar.

I have never seen article numbers used with anything but journals so it seems to me that |article-number= cannot be a global alias of |pages=. Further, as an alias of |pages=, |article-number= would necessarily render the same way that |pages= renders; the article number would fill &rft.pages= instead of &rft.artnum= in the metadata; when an editor wishes to identify two or more specific pages in the source that support en.wiki text, one of |pages= or |article-number= must yield, or the editor must shoehorn both assigned values into one parameter or the other.

Your discard !vote is noted.

—Trappist the monk (talk) 14:14, 11 September 2022 (UTC)

Sandbox version is currently broken to the point of unusability. An article number is an individual identifier for an article. It is not even close to the same thing as an issue number. An article can easily be part of a journal that has volumes and issues; in fact I would expect that to be the case for most journals that use this referencing format. But your hacked-up version doesn't work for that case: if there is an issue number, it doesn't show the article number, regardless of whether pages are also included.

• {{cite journal/new |title=Title |journal=Journal |volume=3 | issue = 1 |article-number=4159}}
• "Title". Journal. 3 (1) 4159.
• {{cite journal/new |title=Title |journal=Journal |volume=3 | issue = 1 |article-number=4159|pages=1–24}}
• "Title". Journal. 3 (1) 4159: 1–24.

If this is to be implemented at all, it must work separately from issue. Your question of whether to tie it to issue makes zero sense, and indicates a fundamental misunderstanding of what article numbers even are. They are a replacement for page numbers, not for issue numbers. —David Eppstein (talk) 05:49, 11 September 2022 (UTC)

Why are you so angry? What is it that gives you the impression that what I did was anything more than skeletal groundwork to test how |article-number= might be implemented and the result rendered?

The article identified in User talk:Citation bot/Archive 33 § Pages vs Issue vs at vs ... is here. That journal apparently does not use issue numbers when it uses article numbers. Because that was my model, I hacked the module suite to reflect that. I then posted the above where I wondered whether |issue= should be supported when |article-number= is used.

Why are you so angry about this incremental process?

—Trappist the monk (talk) 14:14, 11 September 2022 (UTC)

|article-number= now renders with or without |issue=.

—Trappist the monk (talk) 14:37, 11 September 2022 (UTC)

How about focusing on content and not on imagined attitudes of other people?

Next question: Some publications (notably the LIPIcs series of conference proceedings) mix article numbers and page numbers, so that for instance if article number 33 of LIPIcs volume 189 happens to have 17 pages, then it is formatted (both in the official publisher metadata and in the page numbers on the actual pages of the publication) as having a page range of 33:1–33:17, with the article number entirely encoded within the pages and not as a separate parameter. Other sources list both an article number and a number of pages, without assigning compound numbers to the individual pages; the same paper is listed in MathSciNet as "Art. No. 33, 17 pp.", and if it were indexed in zbMATH it would be "Article 33, 17p." The first of these two formats could be handled by putting the compound numbers into a pages parameter, but that is problematic if you want the article number reflected in the CoInS MeTaDaTa or however it's capitalized (does anyone still use cOiNs?). The second is not allowed, because even if you tried to use |article-number=33 |pages=17pp, some bot would complain that you're using the pages parameter wrong and try to "fix" it to something else.

So do you have a suggestion for how to deal with compound pages and with article-number + number-of-pages referencing? You can argue (as we have seen here before) that numbers of pages should not be included in references because they're not used to identify the reference, but clearly they are used to describe it, and that description could be useful to some readers of the reference for instance in trying to figure out how much effort they would have to put in to read the reference. Also, whether they should be included is clearly a matter of opinion rather than a matter of fact, because some well-established sources (MathSciNet) do include it. —David Eppstein (talk) 20:57, 11 September 2022 (UTC)

Perhaps I will when the first words out of your mouth are not shouted. I think my initial post was clear enough for you to know that the code is a prototype yet you chose to shout about its unusability.

The |article-number= proposal is currently constrained to {{cite journal}}. Your paper is, I think, best cited with {{cite conference}} using the pagination as printed in the proceedings. The publisher's BibTeX citation clearly shows that the publisher thinks that the paper is one of a number of papers collected in a proceedings (note that there is no article number there). |article-number= is supported only by COinS journal objects so {{cite conference}} can never fully support |article-number= were we, at some point, to allow that.

As far as I know, cs1|2 has never supported the notion of total pages. There have been several discussions here about that. We could fully support a |tpages= parameter in {{cite book}}, {{cite thesis}}, and other non-periodical templates because COinS has the rft.tpages k/v pair for book and dissertation objects. But, that is a discussion for another time and another place. This discussion is about |article-number= in {{cite journal}}.

—Trappist the monk (talk) 01:05, 12 September 2022 (UTC)

You think journal articles can have article numbers but that conference proceedings papers cannot? Your dogmatic approach to what a citation can be or cannot be is something that causes me to occasionally get frustrated here. People who publish stuff, in various ways, are often flexible in how they define those publications in a way that allows others to find them. Citation formats here must stay as flexible, in order to allow editors to use them to correctly refer to things, and to avoid forcing editors to misuse their parameters because the parameters as used correctly are inadequate to the task. This latest bizarre piece of rigidity, that conference papers are somehow so different from journal papers that they cannot even be thought of as an example of something with an article number even in situations where they obviously do have article numbers, and must be prevented from using similar formatting and parameterization, is a case in point. (Also, fyi, I type with my fingertips, and usually not at the same time as speaking in any way; my mouth is not involved in the process. But your aversion to boldface text for emphasis is noted for future reference. Is italic ok or should I just never emphasize any part of what I write when communicating with you?) —David Eppstein (talk) 01:17, 12 September 2022 (UTC)

This sentence is the only sentence I have written about article number support in conference citations:

|article-number= is supported only by COinS journal objects so {{cite conference}} can never fully support |article-number= were we, at some point, to allow that.

We can choose to support |article-number= in {{cite conference}} as a non-metadata parameter as we do for other parameters (|access-date=, |agency=, |department=, |editor=, |language=, |medium=, ...); parameters that display something but that don't contribute to the citation's metadata. Before we do that, I think that we should figure out how or whether we support |article-number= in {{cite journal}}.

—Trappist the monk (talk) 16:46, 12 September 2022 (UTC)

Incidentally, for a random example of a paper in a conference that its publisher clearly identifies using article numbers, see doi:10.1145/3225058.3225061. In the previous example, the publisher used compound page numbers of the form NN:1–NN:PP, but the databases MathSciNet and zbMATH separated it out as Article number NN, PP pages. In this example, it is reversed: the publisher uses Article number NN, pages 1–PP while the database DBLP [1] uses compound page numbers of the form NN:1–NN:PP. I think we can conclude from these examples that multiple publishers and databases think that these two forms are semantically equivalent and that the choice between one or the other is a matter of style. —David Eppstein (talk) 01:39, 12 September 2022 (UTC)

On second thought, I don't think this deserves all the back-and-forth, it is such a minor issue. The article number, a sparingly used piece of information, is not necessary in order to find an article. People look for articles by title, journal name & date, and by author. Anything else (page range, article number) is ancillary. Article number maybe helpful but it doesn't have enough traction for the effort (technically, both article page range and article number are article representations, just like the article title is). It can be easily input, as noted previously, in |at= if there is overwhelming need. The fact that the metadata scheme chokes (again) on this does not concern this page. We discuss the structure & presentation of citation data, and metadata should follow what is decided here. This is a one-way relationship. By all means fix the metadata, and there's probably no need to waste time telling us about it here. I am certain any participant in this talk page who wants to follow that application knows how to find the relevant project pages. 104.247.55.106 (talk) 12:57, 12 September 2022 (UTC)

Added support for |article-num= in {{citation}} when |journal= has a value:

{{citation/new |title=Title |journal=Journal |volume=XIV |article-number=56 |page=15}}

"Title", Journal, XIV 56: 15

'"`UNIQ--templatestyles-00000032-QINU`"'<cite class="citation cs2">"Title", ''Journal'', <b>XIV</b> 56: 15</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.volume=XIV&rft.artnum=56&rft.pages=15&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 16:46, 22 September 2022 (UTC)

Displaying "n.d." is obscure for readers, "undated" is better

For citations without a date, the abbreviation "n.d." appearing somewhere in the citation is a bit baffling for readers. I would suggest that the displayed citation should show "undated"; the template should allow "n.d" to be entered as at present for compatibility, or "undated". "No date" is other possible clear wording. Best wishes, Pol098 (talk) 12:59, 19 September 2022 (UTC)

Citations are baffling for readers. The reason being that Wikipedia citations were originally, and still, based on citation systems targeting the small minority of readers familiar with the concept and its applications. Because it was the easier thing to do, and was safely within the comfort zone of their field of expertise. For readers, the present system looks quite similar and equally (if not more) baffling. In such a system, "n.d." fits perfectly, and is consistent. It also happens to be common, established cataloguing markup for undated materials. Since the present system just like its ancestors, disregards the needs of the general readership, piecemeal reform will only add confusion. The OP's request should not be applied. 50.75.226.250 (talk) 16:20, 19 September 2022 (UTC)

Most general and book citations using {{citation}} and variants are fairly clear and obvious, as a random look through articles will confirm - they are not terribly baffling. "Archived from the original" becomes obvious the first time it is clicked. While journal citations are more obscure, they're likely to be understood by those who will use them, and the volume, issue, DOI, etc. do not tell the reader anything useful anyway. But the date, in particular, can be important and relevant, and n.d., if used, is the only really obscure part of a citation. A couple of random examples (with date) that are typical, and shouldn't cause anyone any difficulty:

"Maori leaders at odds over flash mob haka". 3 News NZ. 20 September 2011. Archived from the original on 27 December 2011.

Hartigan, Ryan (2011). "Embarrassing Time, Performing Disunity: Rugby, the haka, and Aotearoa – New Zealand in the United Kingdom". Performance Research. 16 (2). Taylor & Francis: 37–43. doi:10.1080/13528165.2011.578728. S2CID 194059694.

So I maintain my suggestion (for discussion, not a request). Best wishes, Pol098 (talk) 20:29, 19 September 2022 (UTC)

I agree. "Undated" or "No date" would be an improvement. Improvement is good, unless the only thing that's good enough is a revolution where we describe each source of information in full sentences. How's this sound?

I got this information at 3 News NZ at the web address http://www.3news.co.nz/Maori-leaders-at-odds-over-flash-mob-haka/tabid/1534/articleID/226469/Default.aspx with the title "Maori leaders at odds over flash mob haka" and the date 20 September 2011. That address doesn't work any more, but now you can get it at https://web.archive.org/web/20111227003042/http://www.3news.co.nz/Maori-leaders-at-odds-over-flash-mob-haka/tabid/1534/articleID/226469/Default.aspx on the Internet Archive where it was copied on 27 December 2011.

Yes I intend that proposal as gentle sarcasm. SchreiberBike | ⌨  21:03, 19 September 2022 (UTC)

The intention is irrelevant. In fact, the verbose explanation above is far more understandable by practically anyone who can read unadorned English, compared to the current shorthand that citations use. Assuming that any random user of the millions of unique users that visit Wikipedia daily ignores the annoyance of the strange in-text (fiootnote) notation and is curious enough to follow it, they will eventually land on a paragraph with additional strange formatting, resembling the writings of someone who cannot form a sentence. Complete with strange terms and numbers, and various forms of names and dates seemingly thrown in haphazardly. Also assuming they have an idea of the basic Wikipedia policy about verification, they will probably wonder why Wikipedia makes it so hard for any reader to do so. With the confusion of footnoting and referencing systems, with all their peculiar characteristics, special cases and exceptions. And they cannot turn to the virtually non-existent documentation for help.

The current system is for those in the know. That category knows exactly what "n.d." means. More than that, they probably expect it, as the professional norm. By adding beginners' formatting to a more or less expert system you do a disservice to both. 71.247.146.98 (talk) 22:59, 19 September 2022 (UTC)

We have used n.d. for an undated publication since its institution along with date checking in CS1 in 2013. A discussion not long after indicated that this is what Chicago, APA, and MLA do. Indeed as 71 implies this is the professional standard for citations (with what was then some consensus on the point; standards have advanced a decade in that time and those citation styles do change, so I haven't looked to see either for new advice from those orgs or contradictory from others).

I don't see a strong reason to differ from those in this regard. The point is that in almost all cases that these will be set off by round brackets, and if a reader hasn't figured out that round brackets indicate a date, I don't know how to help them. That's even if they don't already have their own experience with citations, which I personally gained in high school English.

A few other discussions which I have not perused. Izno (talk) 23:27, 19 September 2022 (UTC)

The strong reason is WP:TECHNICAL. Those style guides are for academic audiences in a context where print space is at a premium. Our style guide is for a general audience under WP:NOTPAPER. "Undated" is much easier to understand than "n.d." —David Eppstein (talk) 00:05, 20 September 2022 (UTC)

@David Eppstein: puts it very well. Our readers (and indeed many of our writers) are not well-versed in the jargon of APA or MLA. "undated" is clear and unambiguous. DuncanHill (talk) 00:08, 20 September 2022 (UTC)

Within the contours of the current system, the n.d. shorthand, which is editor markup predating any citation system, fits nicely among all the other elements. If one is able to read & understand CS1\2 citation shorthand, "n.d." is no mystery.

CS1\2 is not accommodating the general reader on any level (presentation, documentation, ease-of-understanding, verification applicability etc). Half-hearted attempts to help the (presumably inexpert) reader with minor or cosmetic elements are imo placebos that distract and evade.

After all this time, I no longer believe that CS1\2 can ever be a general-purpose citation system understandable by inexpert readers, i.e. fitting an encyclopedia of similar declared goals. It will plod along as a semi-expert system with a confused design philosophy. Within its narrow scope, it can be fractionally, serially improved. Ok, cool. But "Undated" vs or in addition to "n.d." is not an improvement, it's another sideways move. 64.18.11.69 (talk) 01:47, 20 September 2022 (UTC)

This question of "how terse is too terse" comes up every once in a while. I think this is on the line of pp. that outputs with pages in most citations and (1) or 3 that outputs with issue and volume in {{cite journal}}, and even the fact cite journal does not output any indicator of the page number (ok, : 123). If we want to go down the road of arguing that users can't figure out n.d. given the other context clues, then we should look at every other excessive abbreviation, and there are far worse offenders than this one, and I know the discussion here has not been favorable to redoing all those as well. (Especially given the fact that other citation styles do support n.d..) Izno (talk) 02:29, 20 September 2022 (UTC)

Agreed. We've started with other citation guides as a basis, and given that there are some pretty standard abbreviation conventions out there, I don't think we should be ditching many of them, including n.d. It's all find and dandy to spell everything out, but readers are still going to encounter these conventions when they read the source material for their editing here.

That said, I wholeheartedly agree that the terse journal notation style is not as helpful when we also use standard abbreviations "Vol.", "no." and "pp." in other templates. My impression is that it was added as a way to embrace subject-matter experts who are accustomed to such notation, even as we have, or had, a guideline saying that journal names need to be spelled out in full for our generalist audience. I would rather focus on that most terse notation so that our citations have a similar level of abbreviation first before then deciding if other fairly common abbreviations should be changed to full words. Imzadi 1979 → 04:49, 20 September 2022 (UTC)

Opening it up to "undated", "no date", etc., I feel makes harv/sfn-style templates complicated; is there going to be support for (Last n.d.) as well as (Last & Undated), (Last & No date) (already see how these two differ), etc.?

How much evidence is there that readers are even confused by seeing n.d. anyway? Umimmak (talk) 01:30, 20 September 2022 (UTC)

That's hard to tell since relatively few citations on here are specified as having no date. The sample size is too small. Glades12 (talk) 09:40, 20 September 2022 (UTC)

I think anyone familiar with the idea of citations can usually figure out the meaning from looking at them; the formatting Wikipedia has chosen helps. I didn't know what "n.d." meant the first time I saw it but searching for n.d. leads quickly to a page where the last item explains it (probably in violation of the rules for disambiguation pages). Citations are absolutely necessary so we have to have them in some form. I haven't seen a reasonable alternative and writing them out in sentence form seems silly. If we were to eliminate the less obvious things like bold to indicate volume number and ":" for page number and "n.d. meaning no date, that would help. We should help where we can. SchreiberBike | ⌨  13:32, 20 September 2022 (UTC)

I repeat the typical examples, chosen randomly from the haka page, I gave before, which may help to form an opinion. They are totally clear to a new reader, I think, except that the academic journal details - which are absolutely irrelevant when reading an article or linking to a reference - such as volume, issue, DOI, etc. are obscure.

"Maori leaders at odds over flash mob haka". 3 News NZ. 20 September 2011. Archived from the original on 27 December 2011.

Hartigan, Ryan (2011). "Embarrassing Time, Performing Disunity: Rugby, the haka, and Aotearoa – New Zealand in the United Kingdom". Performance Research. 16 (2): 37–43. doi:10.1080/13528165.2011.578728. S2CID 194059694.

Compare with:
"Maori leaders at odds over flash mob haka". 3 News NZ. n.d.

Smith, John (n.d.). "Maori leaders at odds over flash mob haka". 3 News NZ.

Remember also that, depending upon Wikipedia setup, details of references are popped up when hovering over the number in the article text.

I'm concerned only with reader experience, not complying with standards, or editor convenience. Best wishes, Pol098 (talk) 15:06, 20 September 2022 (UTC)

At best, a little coding to auto-format it as n.d. in the output wouldn't be inappropriate if it's truly felt that the abbreviation is that obscure, much as {{circa}} outputs c. for readers. I don't see a need to remove the abbreviation though given that it's common in other citation guides. Imzadi 1979 → 15:20, 20 September 2022 (UTC)

I probably misunderstand, but nobody is suggesting that citations should be done away with. Only that they should be made understandable, so that 1. their relationship to the text (in body or footnote) is unquestionably obvious 2. their path to the verification process a logical, easy conclusion. The OP proposal is schizophrenic, which is no fault of the OP, but reflects the confused design of the Wikipedia citation systems. Simply put, they don't know if they are geared to experts or to the general public. [A]nyone familiar with the idea of citations likely doesn't need to be told what "n.d." means. The majority of readers though are very likely unfamiliar with either the concept or the particulars of citations. For them, adding/changing to "undated" is a meaningless detail in a sea of strange terms parading in an unfathomable sequence. 65.88.88.76 (talk) 16:21, 20 September 2022 (UTC)

I'm not sure whom I'm responding to since a series of IP editors have contributed here, but do you (or anyone else) have a suggestion of a better way to present citations? SchreiberBike | ⌨  22:35, 21 September 2022 (UTC)

I suppose you are responding to the argument, irrespective of the nominal participant. That covers it. Indeed there are suggestions, but this discussion is rather narrow for them to be added here. The main one is systemwide and would involve a "general" and an "expert" mode of presentation. So each would be internally consistent. Another topic. 71.247.146.98 (talk) 12:45, 22 September 2022 (UTC)

language=ga

Why doesn't

• {{cite book|chapter=Óró Sé do Bheatha 'Bhaile|title=Sean-Nós Nua|first=Sinead|last=O'Connor|year=2002|language=ga}}
• O'Connor, Sinead (2002). "Óró Sé do Bheatha 'Bhaile". Sean-Nós Nua (in Irish).

work? I see "in Ga" instead of a more readable description of the Irish language. (I know this is not actually a book; it's just an example.) —David Eppstein (talk) 21:05, 20 September 2022 (UTC)

The Ga language exists. Template:Citation Style documentation/language/doc#Language names lists "ga" and says " When these names are used in |language=, cs1|2 will attempt to validate them but such attempts are not likely to succeed." Imzadi 1979 → 21:23, 20 September 2022 (UTC)

Help:Citation Style 1 says to use two-letter codes. Maybe that advice should be modified in cases where the two-letter code does not work? Alternatively maybe the codes can be considered to be case-sensitive? —David Eppstein (talk) 21:30, 20 September 2022 (UTC)

Where, exactly, does Help:Citation Style 1 [say] to use two-letter codes? cs1|2 supports two- and three-character language tags as well as most of the IETF and IETF-like language tags supported by MediaWiki.

—Trappist the monk (talk) 22:30, 20 September 2022 (UTC)

"Because cs1|2 templates are often copied from en.wiki to other wikis, the use of language codes is preferred so that language names render in the correct language and form: espagnol at a French-language wiki instead of the English word "Spanish"." —David Eppstein (talk) 00:08, 21 September 2022 (UTC)

That sentence only says that use of a language tag is preferred over the use of a language name; the number of characters in the language tag is not mentioned.

—Trappist the monk (talk) 00:33, 21 September 2022 (UTC)

The list of language tags does not provide a language tag for Irish of any length other than the two-letter one. —David Eppstein (talk) 04:25, 21 September 2022 (UTC)

Because MediaWiki does not support the ISO 639-2, -3 tag gle:

{{#language:gle|en}} → gle

—Trappist the monk (talk) 14:30, 21 September 2022 (UTC)

When evaluating the value assigned to |language=, cs1|2 looks first at the list of MediaWiki-supported language name. The evaluation is case-insensitive because editors will write |language=french. So, for |language=ga, cs1|2 finds Ga because that is a language name that MediaWiki supports. Of all of the MediaWiki-supported languages, there are only seven where the language tag is the same as language name; ga (Irish) and Ga (gaa) are the only two where the tag is spelled the same as an unrelated language name. The others are:

{{#language:fon|en}} → Fon

{{#language:isu|en}} → Isu

{{#language:luo|en}} → Luo

{{#language:tiv|en}} → Tiv

{{#language:vai|en}} → Vai

{{#language:yao|en}} → Yao

These, of course, are not a problem.

—Trappist the monk (talk) 22:30, 20 September 2022 (UTC)

place, when publication-place is redundant with work

Consider this citation:

Adam, Karla (15 September 2022). "The British love queues. The queen's death brought one for the ages". The Washington Post. Retrieved 15 September 2022.

The cited article bears a dateline of "London". Per the documentation of {{Cite news}}, it would be appropriate to set |place=London (or |location=London). However, a dilemma is then reached (ignore CS1 maint tags; they're from the styling added for emphasis):

• If |publication-place= is unset, |place= is interpreted to refer to that rather than to the dateline, and the template incorrectly says that The Washington Post is based in London:

  Adam, Karla (15 September 2022). "The British love queues. The queen's death brought one for the ages". The Washington Post. London.{{cite news}}: CS1 maint: location (link)

• If we set |publication-place=Washington, D.C., we violate the rule omit when the name of the work includes the publication place.

  Adam, Karla (15 September 2022). Written at London. "The British love queues. The queen's death brought one for the ages". The Washington Post. Washington, D.C..{{cite news}}: CS1 maint: location (link)

Is there some way to indicate, like, |publication-place=redundant or something? It seems strange to have a system where I can indicate dateline for, say, The Wall Street Journal or The Mercury News, but not for The Washington Post, the Los Angeles Times, The New York Times, etc. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:54, 23 September 2022 (UTC)

I would omit it. It does not help the reader to verify the claim in the article in any way to know that the writer of the article was in London. – Jonesey95 (talk) 19:36, 23 September 2022 (UTC)

Location is where the publication was published, not where a particular item was written - such details don't help to locate the reference and merely confuse the reader.Nigel Ish (talk) 19:38, 23 September 2022 (UTC)

The current documentation in Template:Citation Style documentation/publisher says place: For news stories with a dateline, the location where the story was written. Should that be removed? Or some note added that would limit it to some subset of cases where it's particularly relevant? -- Tamzin^{[cetacean needed]} (she|they|xe) 19:44, 23 September 2022 (UTC)

We've discussed this before:

• Help talk:Citation Style 1/Archive 61 § publication-place, place, or location and their proper use
• Help talk:Citation Style 1/Archive 64 § publication-place, place, or location and their proper use (cont.)
• Help talk:Citation Style 1/Archive 74 § Straw poll: make publication-date and publication-place full synonyms...

A quick scan of those discussions suggests that we should, at the least, make all of |publication-place=, |place=, and |location= into exact-equivalent aliases. Doing that gets rid of the 'written at' dateline stuff because as noted above, where a source was written does nothing to help a reader locate the source. Am I mistaken in my reading of those discussions?

Currently, Category:CS1 location test has 1,295 articles. I can dust off my awb script and let it remove articles where |publication-place= has the same value as |location= or |place=.

—Trappist the monk (talk) 19:52, 23 September 2022 (UTC)

That's how I'd read the consensus across those three discussions, yeah. And I tend to agree. I suppose I could see some scenario, less in the context of news articles and more in the context of letters or poems, where location of writing could have some disambiguatory function? But there will almost always be other ways to disambiguate that. And if we were to have a parameter for that, better a specific |written-at=, with no ambiguity in naming. -- Tamzin^{[cetacean needed]} (she|they|xe) 20:04, 23 September 2022 (UTC)

Fails to throw a DOI error

Holm, Cyril; Lind, Hans; Vogel, Jonas Anund (December 2019). "Incentivising innovation in the construction sector: the role of consulting contracts". Construction Economics and Building. 19 (2): 181–196. doi:10.0.20.10/AJCEB.v19i2.6613. Retrieved 19 September 2022. {{cite journal}}: Check |doi= value (help)

Should throw an error. 10.0.20.10 is not a valid prefix. Headbomb {t · c · p · b} 20:59, 23 September 2022 (UTC)

DOI registrants can be any sequence of digits and dots (see https://www.doi.org/doi_handbook/2_Numbering.html#2.2.2). cs1|2 looks for patterns of digits and dots that aren't yet in use. The live module already catches one and two digit registrants without subcode:

• {{cite journal |journal=Journal |title=Title |doi=10.12/somat}}

  "Title". Journal. doi:10.12/somat. {{cite journal}}: Check |doi= value (help) – two-digit registrant without subcode

• {{cite journal |journal=Journal |title=Title |doi=10.1/somat}}

  "Title". Journal. doi:10.1/somat. {{cite journal}}: Check |doi= value (help) – one-digit registrant without subcode

I have added a test for (presumably) unused one and two digit registrants with subcode:

• {{cite journal/new |journal=Journal |title=Title |doi=10.12.1/somat}}

  "Title". Journal. doi:10.12.1/somat. {{cite journal}}: Check |doi= value (help) – two-digit registrant with subcode

• {{cite journal/new |journal=Journal |title=Title |doi=10.1.1/somat}}

  "Title". Journal. doi:10.1.1/somat. {{cite journal}}: Check |doi= value (help) – one-digit registrant with cubcode

—Trappist the monk (talk) 22:20, 23 September 2022 (UTC)

That they can be is not very important relative to the fact that they aren't. When we start having DOIs that don't start with 10.#### or 10.##### then we can remove that check. Headbomb {t · c · p · b} 22:39, 23 September 2022 (UTC)

Distinguishing between minor and major works in titles

I’m wondering whether it’s possible to detect (from within CS1/Utilities/wrap_style, or elsewhere) which field a particular title is coming from. Thanks!⸺al12si (talk) 19:32, 25 September 2022 (UTC)

(edit conflict) 2× – answer to a post that no longer exists...

As far as I know, that issue has never been discussed here which is why we only have presentation['italic-title'] and presentation['quoted-title'] in Module:Citation/CS1/Configuration. It would seem to me that you also want something like presentation['alt-major-title'] = '《$1》' and presentation['alt-minor-title'] = '〈$1〉' using whatever are the appropriate characters (these are not guillemets but were found at https://unicode.org/charts/nameslist/n_3000.html). How to decide when to switch will require some thought. If we add these, for consistency, we should probably rename ['italic-title'] and ['quoted-title'] to ['major-title'] and ['minor-title'].

I don't know what you mean by Other titles are formatted italic. Does that mean that both major and minor titles are italicized? Does 'roman' really apply to cjk or is that just a loose equivalent to upright (not italicized)?

—Trappist the monk (talk) 20:07, 25 September 2022 (UTC)

To me, the section title and the OP content seem a bit incongruous? Pls elaborate. 50.74.165.98 (talk) 20:20, 25 September 2022 (UTC)

Sorry everyone. I found it out. The key parameter is what I need.—al12si (talk) 20:36, 25 September 2022 (UTC)

Bump PMC limit

• Meiri, S.; Levin, E. (2022). "Revisiting life history and morphological proxies for early mammaliaform metabolic rates". Nature Communications. 13 (1): 5562. doi:10.1038/s41467-022-32715-0. PMC 9508135. PMID 36151068. S2CID 252441695.

This shouldn't throw an error. Headbomb {t · c · p · b} 20:05, 25 September 2022 (UTC)

CS1 flagging seemingly fine url as valid

I recently came across the article /e/ (operating system), which seems to be producing a lot of CS1 errors: URL. However, after looking over some of the URLs being flagged as invalid, I couldn't find any issues with them (E.g. https://doc.e.foundation/how-tos/upgrade-ecloud-storage), so I'm not sure why these are being flagged. URLs dont support ATAW markup, so I can't supress the errors either should they be a false flag. Is there something wrong with this url I'm not noticing, or is this simply a misflag? Aidan9382 _(talk) 20:06, 25 September 2022 (UTC)

Example

• "Service Announcement : 26 May - Forum - /e/ community". 2022-05-29. Archived from the original on 29 May 2022. Retrieved 2022-05-29.

Headbomb {t · c · p · b} 20:10, 25 September 2022 (UTC)

It seems to not like .e. Headbomb {t · c · p · b} 20:12, 25 September 2022 (UTC)

The error urls seem to be missing a valid recognizable suffix, such .org. 50.74.165.98 (talk) 20:17, 25 September 2022 (UTC)

Aside for country-code TLDs (ccTLDs), single-letter second-level domain names are relatively rare. Until now, cs1|2 has only supported four non-ccTLDs that have single-letter second-level domain names: cash, company, org, and today. I have added foundation:

{{Cite web/new |date=2022-05-29 |title=Service Announcement : 26 May |url=https://community.e.foundation/t/service-announcement-26-may/41252?page=2 |website=/e/OS Foundation & Community}}

"Service Announcement : 26 May". /e/OS Foundation & Community. 2022-05-29.

I have also moved the list of these TLDs from the main module to ~/Configuration.

—Trappist the monk (talk) 21:57, 25 September 2022 (UTC)

Considering the more than 1500 active TLDs, with more in the pipeline, this issue will reappear. The .foundation TLD is lightly used (no more than ~30k registrations) even though it has an almost 10-year history. But this may change in the future. 64.18.11.69 (talk) 23:16, 25 September 2022 (UTC)

Request filed

Add tooltip with person-name (or other stand-in name if not a person) over |any-mask=. To properly display the full citation when one hovers over a reflink such as harv, sfn or CITEREF (hover-over-hover). 50.75.226.250 (talk) 15:20, 26 September 2022 (UTC)

Generic citation title request

Could [Ee]rror be added as a new generic citation title? The title appears around 65 times (the regex times out so it may be more), and none of the uses seem to be the intended/correct title. Note that it would need to check if the title is exactly [Ee]rror and not just contains the word [Ee]rror, as there are a lot of regular uses for it in a title. Aidan9382 _(talk) 08:32, 27 September 2022 (UTC)

Cite journal doesn't support chapter= or section=

Unless I'm mistaken somewhere, the documentation for {{Cite journal}}, specifically, includes parameters chapter= and section=; they generate a CS1 error. I haven't checked the documentation for other templates, but:

"Citation Style 1 templates {{cite web}}, {{cite news}}, {{cite journal}}, {{cite press release}}, {{cite podcast}}, {{cite newsgroup}}, as well as template {{citation}} when it uses |work= or any of its aliases, do not support |chapter= or the aliases |contribution=, |entry=, |article=, or |section=."

Best wishes, Pol098 (talk) 12:40, 29 September 2022 (UTC)

Are you sure? The documentation for {{cite journal}} does not include |chapter= and |section= cf. Template:Cite journal § Title with Template:Cite book § Title (which does include and support |chapter=).

Template:Cite journal § TemplateData lists |chapter= (it shouldn't – but that is TemplateData which really has no business acting as template documentation...) Can you point to anywhere else that you think that {{Cite journal}}, specifically, includes parameters chapter= and section=? The same question for {{cite web}}, {{cite news}}, {{cite magazine}}, {{cite press release}}, {{cite podcast}}, {{cite newsgroup}} and {{citation}} when it uses |work=. Do you see anywhere that says that these templates support |chapter= and aliases?

Am I misunderstanding the purpose of your posting?

—Trappist the monk (talk) 13:12, 29 September 2022 (UTC)

Do you see anywhere that says that these templates support |chapter= and aliases?:

From Template:Cite journal - "COinS metadata is created for these parameters:
Note: This table of metadata is displayed for all Citation Style 1 templates. Not all of these parameters are supported by every CS1 template. Some of these parameters are mutually exclusive, some are aliases of another parameter, and some require other parameters to be present. Please refer to each template's documentation for a full list of supported parameters, their aliases, and their dependencies."

But this caveat appears in the {{cite journal}} documentation. This may be too trivial an issue to be worth doing anything about, but as far as I can see it's misleading. In my case, I added a journal reference where a specific table was relevant, so I looked at the {{cite journal}} documentation ("journal", specifically, not "citation"), saw that "chapter=" was stated to be supported, and added "chapter=Table 3". I'm not asking for anything to be done (and might be misguided anyway), just pointing this out for what it's worth.
Best wishes, Pol098 (talk) 15:07, 29 September 2022 (UTC)

I'm confused. The note that you quote above, added 10 January 2020 by Editor Jonesey95, clearly says that the parameters listed in the COinS-supported parameter list may not be supported by all cs1|2 templates. Apparently you disregarded that and assumed that the mere mention of |chapter= anywhere in the {{cite journal}} documentation page means that that parameter is supported by {{cite journal}}. If you can reword the COinS parameter-list note in a way that is more clear, please do so.

—Trappist the monk (talk) 15:28, 29 September 2022 (UTC)

Many thanks for your help. I don't think there's anything to do, but I'll try to clarify any confusion - don't waste any more time on this. I obviously didn't read through all the documentation for {{cite journal}} but searched for "chapter" which seemed a useful parameter for my purpose, and found "chapter=", which generated an error. Further reading found that this was in a general list of COinS metadata embedded in the documentation, which said "refer to each template's documentation". As far as I was concerned I was looking at the cite journal documentation. In fact, what I should have been doing was looking at the beginning of the displayed page, where "content=" was not mentioned. I continue to think that this is somewhat confusing, but not a serious problem.

[Added later] After a bit of thought I propose to modify the introductory paragraph of the COinS-supported parameter list to read: "Note: This table of metadata is displayed in the documentation of all Citation Style 1 templates. Not all of these parameters are supported by every CS1 template. Some of these parameters are mutually exclusive, some are aliases of another parameter, and some require other parameters to be present. A full list of a particular template's supported parameters, their aliases, and their dependencies are shown in the Usage section near the top of its documentation page." Should I do this, and is it the best wording? Best wishes, Pol098 (talk) 17:00, 29 September 2022 (UTC)

I've now made the change proposed above to Template:Citation Style documentation/coins, for better or worse. Best wishes, Pol098 (talk) 21:48, 30 September 2022 (UTC)

author-link=interlanguage

Some calls use an interlanguage prefix in author-link. insource:"author-link=:de:" find 800 cases with German links, e.g. {{Cite book|title=Goethes späte Liebe|last=Gersdorff|first=Dagmar von|year=2005|author-link=:de:Dagmar von Gersdorff|publisher=Insel Verlag|isbn=978-3-458-19265-7|language=de}}:

• Gersdorff, Dagmar von [in German] (2005). Goethes späte Liebe (in German). Insel Verlag. ISBN 978-3-458-19265-7.

Should the interlanguage link be detected and marked, or maybe something more advanced like {{Interlanguage link}}? {{ill|Dagmar von Gersdorff|de}} produces Dagmar von Gersdorff. PrimeHunter (talk) 15:04, 1 October 2022 (UTC)

I don't see how interlanguage links in any role parameter (author, editor etc.) help in understanding the citation or finding the cited material. Even when the link is in en wiki, this is more of a convenience. The only utility I can think of in en wiki is that by following the link an interested reader may disambiguate common person names in the related roles.

Imo, such interlanguage links are unhelpful for local-language readers, and potentially confusing. It would be better to disallow them altogether. 64.18.11.67 (talk) 23:17, 1 October 2022 (UTC)

Links to authors, titles, in some cases publishers, have a purpose beyond finding the source. Interlanguage links for authors/editors have been discussed here several times, and it seems that {{ill}} is not going to be supported. The obvious workaround is to construct a manual citation. -- Michael Bednarek (talk) 00:54, 2 October 2022 (UTC)

If by "local-language" readers you mean users of the English language Wikipedia, a large percentage of the readers have English as a second language (or third, or fourth) so having links in other languages may well be helpful to them. In addition, many native English speakers appreciate having a link to a foreign language article when one is not available in English. Finally, monolinguals are a minority in the world, and most people speak more than one language, and English is very often the language of choice. Disallowing such links would hurt a lot of people, without helping anyone, as far as I can see. Mathglot (talk) 10:07, 2 October 2022 (UTC)

I don't think these comments are relevant. Citations exist to apply WP:V, not to accommodate whatever bright extraneous ideas one has. It is bad enough that they may be barely understood by the average reader. They should at least quickly and easily lead the reader to proof. Local-language articles can be more speedily (and generally, properly) be verified by local-language citations, for all local wikis. Whether readers may be multi-lingual or not is neither here nor there and does not concern citations. Some non-local-language info is pertinent and the rationale clearly understandable (original titles of translated works for example). Some local-language links are also pertinent: contributors may have identical names; publisher info may be crucial as publishers are often repositories of last resort when a work is out of circulation. But foreign-language links are just confusing, out of place, and not really helpful to verification. Remove. 2603:7000:2B42:BB00:15B3:D925:DAF2:50D4 (talk) 14:37, 2 October 2022 (UTC)

I find the {{ill}} rendering to be ugly and cryptic. For identifiers used in cs1|2 templates, we provide links to descriptive pages so that readers can learn what the the unfamiliar initialisms (ISBN, doi, PMID, etc) mean. {{ill}} gives a big redlink and a smaller WikiMedia language tag that if clicked takes the reader to a non-English site; its even possible to use {{ill}} to link out of MediaWiki (see the list at meta:Interwiki map):

{{ill|0389790|imdbtitle|lt=Bee Movie}} → Bee Movie

Yeah, we can detect the language prefix; we can test to see if the article name exists at en.wiki (that test is expensive); we can mimic {{ill}} but that mimicry is ugly and cryptic. Because we know what the language tags translate to, we could create something that is less cryptic:

|author=Dagmar von Gersdorff |author-link=:de:Dagmar von Gersdorff

which might render as:

Dagmar von Gersdorff [in German]

or don't bother linking to a nonexistent article and render as:

Dagmar von Gersdorff [in German]

Both are still ugly but much less cryptic. What does the template do when en.wiki has a matching article? Revert to the normal wikilinked author name? Add a maintenance category akin to Category:Interlanguage link template existing link to track no-longer-needed inter-wikilinked authors? What to do when en.wiki has an article for 'EB Greene' the submarine captain but the interwiki points to ':xx:EB Greene' the poet?

Maybe, if we do this, it is best to simply annotate the interwiki:

Dagmar von Gersdorff [in German]

—Trappist the monk (talk) 13:03, 2 October 2022 (UTC)

I think we should make some sort of change, per WP:EGG, and IMO the final option is the best one. It is simple and clean. We should not have Easter egg links that look just like en.WP links but drop readers on a foreign-language page. – Jonesey95 (talk) 02:07, 3 October 2022 (UTC)

Sandbox version of the OP citation:

Gersdorff, Dagmar von [in German] (2005). Goethes späte Liebe (in German). Insel Verlag. ISBN 978-3-458-19265-7.

The module will accept valid language tags that exist in the MediaWiki interwiki map:

{{cite book/new |title=Title |author=EB Greene |author-link=:simple:EB Green}}

EB Greene [in Simple English]. Title.

For known interwiki prefixes, the module will use the MediaWiki-supported language name unless the prefix is in the cs1|2 override table:

{{cite book/new |title=Title |author=EB Greene |author-link=:als:EB Green}} – an override: Mediawiki returns Alemannic

EB Greene [in Tosk Albanian]. Title.

MediaWiki knows about bla as a language tag for Siksiká (which cs1|2 overrides to Blackfoot) but there is no bla.wiki so the module emits and error message:

{{cite book/new |title=Title |author=EB Greene |author-link=:bla:EB Green}}

EB Greene. Title. {{cite book}}: Check |author-link= value (help)

The value in |author= can be interwiki-linked:

{{cite book/new |title=Title |author=[[:chr:EB Green|EB Greene]]}}

EB Greene [in Cherokee]. Title.

When the interwiki prefix is not recognized, the module unlinks the name and emits an error message:

{{cite book/new |title=Title |author=EB Greene |author-link=:xx:EB Green}}

EB Greene. Title. {{cite book}}: Check |author-link= value (help)

{{cite book/new |title=Title |author=[[:xx:EB Green|EB Greene]]}}

EB Greene. Title. {{cite book}}: Check |author= value (help)

and works for the other names:

{{cite book/new |title=Title |editor=[[:sco:EB Green|EB Greene]]}}

EB Greene [in Scots] (ed.). Title.

{{cite book/new |title=Title |translator=[[:sco:EB Green|EB Greene]]}}

Title. Translated by EB Greene [in Scots].

{{cite book/new |title=Title |interviewer=[[:sco:EB Green|EB Greene]]}}

Title. Interviewed by EB Greene [in Scots].

—Trappist the monk (talk) 18:55, 3 October 2022 (UTC)

Of course, because this is Wikipedia, it's never a easy as that ... The module chokes on interproject prefixes: :s: for Wikisource, :d: for Wikidata, etc. because they aren't in the interwiki map that cs1|2 currently uses (Module:Citation/CS1/Configuration builds a map that is language tags only):

{{cite book/new |author-first=Vitaly |author-last=Feldman |author-link=:d:Q102311396 |title=Title}}

Feldman, Vitaly [at Wikidata]. Title.

I have to think about this.

—Trappist the monk (talk) 19:38, 3 October 2022 (UTC)

Waste of time. Why should there be any link to another-language wiki? It does nothing for the citation except add clutter. 65.88.88.69 (talk) 19:32, 3 October 2022 (UTC)

I think Trappist the monk's proposal is an improvement. Support for d: would even be better. Links to non-English articles of authors serve the same purpose as links to English articles do. -- Michael Bednarek (talk) 00:35, 4 October 2022 (UTC)

The only valid reason for links other than the source is disambiguation of citation content (in case of names/terms such us "Smith, John" "Times Publishing" etc), explanation of citation terms that may help the reader discover the source (such as "hardcover" "jpeg" etc) or information about citation content that can help locate the source if unavailable (such as the particulars of a publisher or online provider). Even then, all links other than to the citation source (via URL or identifier) are suspect. This is obvious, but let's spell it out: the targets of these links must be verifiable and reliable themselves in order to be used as citation-related material. What use is a link to an author page in Wikipedia or anywhere, if that page has no citations, or its citations are self-serving, biased or unreliable? Citations are used to prove claims, not add claims related to the citation itself. It is even worse for foreign-language links which do not belong (as reader material) in the first place, and whose provenance is much harder for a non-speaker to discern. What a waste of time and code. 74.64.150.19 (talk) 12:00, 4 October 2022 (UTC)

Links for authors, editors, titles, even publishers, provide a quick prima facie check for the reputation, or lack of it, of the source, especially where the citation itself is not readily available to the reader. -- Michael Bednarek (talk) 12:26, 4 October 2022 (UTC)

And why is it presumed that the link targets present authors etc. (and their reputations) in a reliable fact-based manner? This justification for links is shaky and imo should be avoided in general, but especially where foreign-language articles are used as targets. As stated, there can be legitimate uses of non-foreign language links, that may help clarify a citation for the reader. Also, citations are used to prove specific claims made in wikitext, and their reliability should be judged at that level. An author that has been proven disreputable in the past may make a truthful and insightful statement about a certain subject. Using that statement as a citation that proves a specific wikitext claim is a reliable reference. It is up to the wiki contributor to note that the author, not the content of the source, is controversial. Outside of the citation, perhaps in a footnote or the wikitext itself. Conversely for authors, publishers etc. with a reputable history. They may be responsible for untrue (knowingly or not makes no difference) and/or biased statements relative to the specific wikitext. Such reference would be unreliable. 50.74.1.34 (talk) 20:19, 4 October 2022 (UTC)

The sandbox module now supports a limited selection of single-letter inter-project prefixes. The supported prefixes are :d: (wikidata), :s: (wikisource), and :w: (wikipedia). Here is the wikidata example from above:

{{cite book/new |author-first=Vitaly |author-last=Feldman |author-link=:d:Q102311396 |title=Title}}

Feldman, Vitaly [at Wikidata]. Title.

name linked to a wikisource article:

{{cite news/new |url=http://www.defenselink.mil/news/newsarticle.aspx?id=25798 |title=Guantanamo Troops Deployed in Unusual Surroundings |publisher=[[American Forces Press Service]] |author=Kathleen T. Rhem |author-link=:s:Author:Kathleen Rhem |date=February 25, 2005 |access-date=2008-01-25}}

Kathleen T. Rhem [at Wikisource] (February 25, 2005). "Guantanamo Troops Deployed in Unusual Surroundings". American Forces Press Service. Retrieved 2008-01-25.

name linked to wikipedia with a :w: prefix. The module looks at the current project and if that project is a Wikipedia project, the name is not annotated:

{{cite book/new |last1=Goffart |first1=Walter |author-link1=:w:Walter Goffart |year=2006 |title=Barbarian Tides: The Migration Age and the Later Roman Empire |url=https://books.google.com/books?id=dM3kdRzztiIC |publisher=[[:w:University of Pennsylvania Press |University of Pennsylvania Press]] |isbn=9780812200287}}

Goffart, Walter (2006). Barbarian Tides: The Migration Age and the Later Roman Empire. University of Pennsylvania Press. ISBN 9780812200287.

similarly, if the local wiki's language code matches the language prefix, the language prefix is not annotated; here neither of :w: and :en: annotate the name:

{{cite book/new |last=Saxby |first=Jessie M.E. |author-link=:w:en:Jessie Saxby |date=1879 |title=Geordie Roye, or, A waif from the Greyfriars Wynd |location=Glasgow |publisher=John S. Marr & Sons |id={{OCLC |61514787 |show=all}} |url=https://ufdc.ufl.edu/UF00047777/00001}}

Saxby, Jessie M.E. (1879). Geordie Roye, or, A waif from the Greyfriars Wynd. Glasgow: John S. Marr & Sons. OCLC 61514787 (all editions).

the order of the prefixes can be swapped, the module does not annotate the name:

{{cite book/new |last=Saxby |first=Jessie M.E. |author-link=:en:w:Jessie Saxby |date=1879 |title=Geordie Roye, or, A waif from the Greyfriars Wynd |location=Glasgow |publisher=John S. Marr & Sons |id={{OCLC |61514787 |show=all}} |url=https://ufdc.ufl.edu/UF00047777/00001}}

Saxby, Jessie M.E. (1879). Geordie Roye, or, A waif from the Greyfriars Wynd. Glasgow: John S. Marr & Sons. OCLC 61514787 (all editions).

for :w: at another-language wiki, the name is annotated with the language:

{{Cite book/new|title=Goethes späte Liebe|last=Gersdorff|first=Dagmar von|year=2005|author-link=:w:de:Dagmar von Gersdorff|publisher=Insel Verlag|isbn=978-3-458-19265-7|language=de}}

Gersdorff, Dagmar von [in German] (2005). Goethes späte Liebe (in German). Insel Verlag. ISBN 978-3-458-19265-7.

for project prefixes that aren't supported, the module does not link the name and emits an error message:

{{cite book/new |title=Title |author=EB Greene |author-link=:v:EB Green}}

EB Greene. Title. {{cite book}}: Check |author-link= value (help)

even when combined with a valid language prefix:

{{cite book/new |title=Title |author=EB Greene |author-link=:v:sco:EB Green}}

EB Greene. Title. {{cite book}}: Check |author-link= value (help)

—Trappist the monk (talk) 00:53, 5 October 2022 (UTC)

Translations of "website is for sale"

Thanks for having "website is for sale" on this list (https://en.wikipedia.org/wiki/Help:CS1_errors#generic_title). There are some translations of this phrase that are also common:

1. German: "Website steht zum Verkauf" as in List of South Korean festivals. The phrase is accompanied by a company's name: "buyeotour".
2. French: "site web est à vendre" as in former version https://en.wikipedia.org/w/index.php?title=Jupiter_(factory)&oldid=1105926591. (?possibly accompanied by a company's name: "Neqo.be"?)
3. Maybe more phrases in more foreign languages.

In a former version of Piedmont Henry Hospital (before i edited on it), my virus scanner / security package warned that the link is potentially harmful.

This has been the subject of the archived discussion Wikipedia:Teahouse/Questions/Archive 1164#Websites for sale as a reference. (I am not interested in the subjects of the articles mentioned above, i came to the articles while repairing nbsp accidents, i.e. articles where "nbsp" is displayed accidently in the read view. I am de-N, en-2.) --Himbeerbläuling (talk) 14:34, 2 October 2022 (UTC)

This search finds about 100 of the German titles while this search for the French finds none – French search not constrained to text in cs1|2 templates. Is that enough to cause us to add the German to the list of generic titles? Where should the threshold be?

—Trappist the monk (talk) 15:42, 2 October 2022 (UTC)

I repeat: My virus scanner / security package warned that the link is potentially harmful. (I am fearful: Does Wikipedia put the users' computers at risk?) --Himbeerbläuling (talk) 06:57, 4 October 2022 (UTC)

Numbered series

1. How do I convey the series volume number? volume= is used for "one publication published in several volumes", not for a series number.
2. What if an individual is credited as both editor and contributor?

E.g. "O'Brien, Phillips, Technology and Naval Combat in the Twentieth Century and Beyond. London: Frank Cass. 2001. ISBN 0-415-44936-7 (Naval Policy and History No. 13) (Editor and contributor)"

• {{cite book | last=O'Brien | first=Phillips | title=Technology and Naval Combat in the Twentieth Century and Beyond | publication-place=London | publisher=Frank Cass | year=2001 | ISBN=0-415-44936-7 | series=Naval Policy and History | volume=13}}
• O'Brien, Phillips (2001). Technology and Naval Combat in the Twentieth Century and Beyond. Naval Policy and History. Vol. 13. London: Frank Cass. ISBN 0-415-44936-7.

—Agentbla ^(talk) 14:51, 2 October 2022 (UTC)

Not obvious to me that series information is needed. Perhaps if there were multiples of the same author and title. Does that apply for this case?

In your above example, O'Brien is the editor because you have not cited a chapter for which he is the author/contributor so:

• {{cite book |editor-last=O'Brien |editor-first=Phillips |title=Technology and Naval Combat in the Twentieth Century and Beyond |location=London |publisher=Frank Cass |date=2001 |isbn=0-415-44936-7}}

  O'Brien, Phillips, ed. (2001). Technology and Naval Combat in the Twentieth Century and Beyond. London: Frank Cass. ISBN 0-415-44936-7.

when citing a chapter:

• {{cite book |last=O'Brien |first=Phillips |chapter=Politics, Arms Control and US Naval Development in the Interwar Period |editor-last=O'Brien |editor-first=Phillips |title=Technology and Naval Combat in the Twentieth Century and Beyond |location=London |publisher=Frank Cass |date=2001 |isbn=0-415-44936-7}}

  O'Brien, Phillips (2001). "Politics, Arms Control and US Naval Development in the Interwar Period". In O'Brien, Phillips (ed.). Technology and Naval Combat in the Twentieth Century and Beyond. London: Frank Cass. ISBN 0-415-44936-7.

or omit |editor-first=:

• {{cite book |last=O'Brien |first=Phillips |chapter=Politics, Arms Control and US Naval Development in the Interwar Period |editor-last=O'Brien |title=Technology and Naval Combat in the Twentieth Century and Beyond |location=London |publisher=Frank Cass |date=2001 |isbn=0-415-44936-7}}

  O'Brien, Phillips (2001). "Politics, Arms Control and US Naval Development in the Interwar Period". In O'Brien (ed.). Technology and Naval Combat in the Twentieth Century and Beyond. London: Frank Cass. ISBN 0-415-44936-7.

—Trappist the monk (talk) 15:24, 2 October 2022 (UTC)

Just in these archives, we've discussed series numbers a few times. Izno (talk) 16:23, 2 October 2022 (UTC)

Re "Not obvious to me that series information is needed": Series information often provides useful information about what kind of book it is. For instance, if a book is listed in Graduate Texts in Mathematics, I can tell just looking at the citation that it's going to be written as a textbook, but probably an advanced one. If it's in Lecture Notes in Computer Science, on the other hand, it's either a conference proceedings or (in rare cases) a research monograph, and I know that I can get subscription access to it through my employer. If it's in LIPIcs then it's definitely a conference proceedings and moreover open access. The number of a volume within a series can be useful for finding the volume in a library or online in exactly the same way that the number of a journal volume can be useful. So it's a useful part of a citation for readers. As an editor, if I see a citation to a book in a series for conference proceedings, but cited as a whole book, then that's a reason for me to look closer at what is likely an insufficiently specific citation. There's a reason that this is a standard part of BibTeX data, for instance. —David Eppstein (talk) 01:47, 4 October 2022 (UTC)

'and others' rejected

The markup:

{{cite journal |last1=Dolan |first1=Ben |last2=and others |title=Thermal Birding |journal=Life Cycle |date=Spring 2017 |page=16 |url=https://www.bto.org/sites/default/files/publications/life-cycle_issue-5.pdf}}

currently gives an error:

Dolan, Ben; et al. (Spring 2017). "Thermal Birding" (PDF). Life Cycle: 16. {{cite journal}}: Explicit use of et al. in: |last2= (help)

yet the original work literally cites "Ben Dolan and other members of the group" as the authors. The help page only suggests using |display-authors=, which does not appear to be appropriate in this situation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 7 October 2022 (UTC)

{{cite journal |last1=Dolan |first1=Ben |display-authors=etal |title=Thermal Birding |journal=Life Cycle |date=Spring 2017 |page=16 |url=https://www.bto.org/sites/default/files/publications/life-cycle_issue-5.pdf}}: Dolan, Ben; et al. (Spring 2017). "Thermal Birding" (PDF). Life Cycle: 16. Izno (talk) 18:35, 7 October 2022 (UTC)

Thank you. I was thrown by the description of |display-authors= at Help:Citation Style 1#Display options, which opens "Controls the number of author or editor names that are displayed when a citation is published.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 7 October 2022 (UTC)

Broken tag in Red Latter Days

https://en.wikipedia.org/wiki/Red_Letter_Days citation 7 Editor, Alistair Osborne, Associate City (2005-08-01). "Red Letter Days experiences a plunge into administration". Daily Telegraph. ISSN 0307-1235. Retrieved 2019-02-07. {{cite news}}: Empty citation (help): |last= has generic name (help) please assist me, I need help repairing it. 06:41, 8 October 2022 (UTC) Lmharding (talk) 06:41, 8 October 2022 (UTC)

Done. The author's title is not part of his name. -- Michael Bednarek (talk) 07:07, 8 October 2022 (UTC)

Reconsider throwing an error on ZWJ sequences?

The template currently errors if the title parameter contains an unescaped instance of U+200D ZERO WIDTH JOINER (‍). This disrupts seemingly legitimate use of Emoji ZWJ sequences (such as 🏴‍☠️, and 🏳️‍🌈, and most gender/skin tone modifiers), which can occur occasionally in the text of Tweets and Instagram posts. See for example this error (which inspired me to leave this comment). To avoid the error, 🏴‍☠️ has to be rewritten as 🏴‍☠️. Am I mistaken in thinking that unescaped ZWJ sequences are valid Wikitext? Is it feasible to remove the ZWJ from the warnings about invisible chars? Alternatively, could the Module attempt to exclude instances of ZWJ which form a valid Emoji? –RoxySaunders 🏳️‍⚧️ (💬 • 📝) 20:31, 8 October 2022 (UTC)

We can't know what constitutes a valid emoji. What can be done and is done today is for some cases to be whitelisted. Izno (talk) 22:49, 8 October 2022 (UTC)

Are you sure? You wrote: To avoid the error, 🏴‍☠️ has to be rewritten... If I pretend that a variant of that sentence fragment is the title of a book:

{{cite book |title=To avoid the error, 🏴‍☠️ and 🏳️‍🌈 have to be rewritten...}}

To avoid the error, 🏴‍☠️ and 🏳️‍🌈 have to be rewritten...

No error message.

cs1|2 has a table of emoji characters that are allowed to follow U+200D ZWJ at Module:Citation/CS1 line 907. I think that we got that table from Unicode emoji-zwj-sequences.txt – whether it is that version or an earlier version I do not know. The skull and crossbones is character U+2620 and is listed in our table and in the Unicode data. The rainbow is character U+1F308 and is listed in our table and in the Unicode data.

From your error example, the sequence of characters is U+1F3F3 WAVING WHITE FLAG, U+FE0F VARIATION SELECTOR-16, U+200D ZERO WIDTH JOINER, U+26A7 MALE WITH STROKE AND MALE AND FEMALE SIGN, U+FE0F VARIATION SELECTOR-16. I am not an Instagram subscriber so I can't say for sure, but the one view that they let me see, it looked to me like the same visual rendering as our template's rendering at Charlie McDonnell (and the same as your signature). The U+1F3F3 and the U+26A7 symbols do not blend into a single compound symbol as the pirate and rainbow flags do.

The reason for this, I suspect, is that Unicode does not include the U+26A7 symbol in their emoji-zwj-sequences.txt file. Because they don't, we don't. My browser, chrome current, does not combine U+1F3F3 and U+26A7.

I should write some code to extract emoji characters allowed to follow U+200D so that when Unicode update their .txt file, it is easier to update our table. @Editor Jonesey95: If I remember correctly, you were instrumental in compiling our list of emoji characters. What was your source?

—Trappist the monk (talk) 23:29, 8 October 2022 (UTC)

I think Archive 74 from January 2021 is where we made some useful changes around emoji modifiers. I see that I somewhat unhelpfully described my creation of our initial list as getting a list from here (this link is version 15; January 2021 was version 12) and then "I did a bunch of text processing", with no further explanation. For the record, it appears that I found every emoji code that followed U+200D, then sorted and deleted duplicates. Last time, I came up with 37 unique lines. This time, I came up with 11 new ones:

U+200D U+1F4A8
U+200D U+1F4AB
U+200D U+1F32B
U+200D U+1F37C
U+200D U+1F384
U+200D U+1F525
U+200D U+1FA79
U+200D U+1FAF2
U+200D U+2B1B 
U+200D U+26A7
U+200D U+2744

The "transgender symbol", U+26A7, is one of the new ones, and it is causing the error in the article version linked above, so it makes sense that it would be a new, currently unsupported (by CS1) modifier. If those new items can be added to the CS1 sandbox, I think it may resolve the above problem. This process will presumably need to be repeated occasionally as the list of emojis are versioned up and new modifiers are added. – Jonesey95 (talk) 00:00, 9 October 2022 (UTC)

(edit conflict) I made some incorrect assumptions about what was happening behind the scenes here (i.e. that a whitelist did not exist), and was thus mistakenly assumed this would affect all emoji sequences. However, 🌈 and ☠️ are correctly whitelisted here. The character ⚧️, which makes up the latter half of the 🏳️‍⚧️ emoji, is not whitelisted, which is what actually triggered the issue I ran into here.

As noted in the latest revision of emoji-zwj-sequences.txt, the sequence 🏳+ZWJ+⚧️ is a valid Emoji, and has been since January 2020. On up-to-date systems, it displays as Transgender Flag. This glyph became RGI in Unicode v13.0, one version after the txt file (from v12.0) which you pointed to.

So it seems the CS1 config just needs to be updated to include characters from new sequences added since v12.0. But to avoid that repeated maintenance, shouldn't the module should simply accept all ZWJ characters that precede an Emoji, regardless of RGI status? As defined by Unicode here, all sequences of Emoji (and Emoji modifiers) connected by ZWJ's are valid, parseable "emojis", even if they don't map to glyphs that are RGI or widely implemented. The likelihood that someone inserted an invalid ZWJ into a citation template by mistake seems far less likely than the likelihood that the person who wrote that source used a computer which supports new sequences that the citation Module isn't keeping up with (as occured here). –RoxySaunders 🏳️‍⚧️ (💬 • 📝) 00:02, 9 October 2022 (UTC)

Good detective work. And unfortunately, people do insert (or copy-paste) ZWJs into citations by mistake, which is one of the reasons that the error category tracks them. – Jonesey95 (talk) 00:05, 9 October 2022 (UTC)

As an aside, Trappist the monk, your browser's ability to render newly standardized Emoji characters depends on the Emoji font installed in your operating system, not on the browser version. I believe Windows 10 tends to lag rather far behind the latest versions in that respect. –RoxySaunders 🏳️‍⚧️ (💬 • 📝) 00:06, 9 October 2022 (UTC)

to avoid that repeated maintenance, shouldn't the module should simply accept all ZWJ characters that precede an Emoji No. We chose to have a short whitelist because Unicode in their wisdom(?) have scattered emoji characters all across the code-point range which makes it much more difficult and time consuming to decide if 'that' character is an emoji. The current mechanism is fast and relatively small.

I'll spend some time tomorrow hacking some code to read an emoji-zwj-sequences.txt file. V15 is the current version?

—Trappist the monk (talk) 00:49, 9 October 2022 (UTC)

Version 15 appears to be the most recent. If you go to this page and click the Charts link, you get version 15. – Jonesey95 (talk) 01:03, 9 October 2022 (UTC)

@Trappist the monk: I see; I had hoped that Lua's string library supported for Unicode property matching (as JavaScript's regex does, via the \p{Emoji} escape), but I've since disabused myself of that notion, so I guess it is necessary to keep a master-list of every plausible Emoji (or range of Emojis) that could appear as part of a sequence. I finagled for a bit, and (as far as I can tell), as of Emoji v15.0, the full set of characters that could follow a ZWJ as part of an RGI ZWJ sequence is:

‍❤️,‍👨,‍💋,‍👦,‍👧,‍👩,‍🤝,‍🧑,‍🎄,‍🫲,‍⚕️,‍⚖️,‍✈️,‍🌾,‍🍳,‍🍼,‍🎓,‍🎤,‍🎨,‍🏫,‍🏭,‍💻,‍💼,‍🔧,‍🔬,‍🚀,‍🚒,‍🦯,‍🦼,‍🦽,‍♀️,‍♂️,‍🦰,‍🦱,‍🦲,‍🦳,‍🔥,‍🩹,‍⚧️,‍🌈,‍☠️,‍⬛,‍🦺,‍❄️,‍🗨️,‍💨,‍💫,‍🌫️

I found that list by running this script on the zwj-sequences.txt page:

const searchSequenceChars = () => {
    // input: emoji-zwj.sequences.txt
    let txt = document.body.innerText;
    // search for an emoji character following a ZWJ
    let zwjEmojis = txt.match(/(?<=\u200D)\p{Emoji}/gu);
    let uniq = [...new Set(zwjEmojis)]; // remove duplicates
    return uniq;
}
const printCodePoints = (chars) => {
    let out = chars
        .map(c => `${c} U+${c.codePointAt(0).toString(16).toUpperCase()}`)
        .join('\n');
    console.log(out);
}    
printCodePoints(searchSequenceChars());

Of these, the ones that aren't currently accounted for in the invisible_chars function are:

🎄 U+1F384 : CHRISTMAS TREE
🫲 U+1FAF2 : LEFTWARDS HAND
🍼 U+1F37C : BABY BOTTLE
🔥 U+1F525 : FIRE
🩹 U+1FA79 : ADHESIVE BANDAGE
⚧️ U+26A7 : MALE WITH STROKE AND MALE AND FEMALE SIGN {transgender}
⬛ U+2B1B : BLACK LARGE SQUARE
❄️ U+2744 : SNOWFLAKE
💨 U+1F4A8 : DASH SYMBOL
💫 U+1F4AB : DIZZY SYMBOL
🌫️ U+1F32B : FOG

–RoxySaunders 🏳️‍⚧️ (💬 • 📝) 02:57, 9 October 2022 (UTC)

Again, good detective work. That's the same list I ended up with above. – Jonesey95 (talk) 05:02, 9 October 2022 (UTC)

Created Module:Make emoji zwj table from which I have updated Module:Citation/CS1/Configuration/sandbox:

{{Cite web/new |last=McDonnell |first=Charlie |date=2022-10-07 |title="Gender reveal 🏳️‍⚧️ Still going by Charlie but the new pronouns are she/they!" |url=https://www.instagram.com/p/CjYa6wVrd3O/ |access-date=2022-10-08 |website=[[Instagram]] |language=en}}

McDonnell, Charlie (2022-10-07). ""Gender reveal 🏳️‍⚧️ Still going by Charlie but the new pronouns are she/they!"". Instagram. Retrieved 2022-10-08.

—Trappist the monk (talk) 19:25, 9 October 2022 (UTC)

Template:Cite magazine

Is there any way to convert this into a regular style ref like {{Cite web}} that can be added via VisualEditor? Kailash29792 (talk) 04:30, 10 October 2022 (UTC)

{{cite magazine}}, like {{cite web}}, is a cs1 template; both are rendered by Module:Citation/CS1 so there is nothing to convert. If {{cite magazine}} does not work with visual editor then you need to be talking with whomever it is that maintains ve. If {{cite magazine}} doesn't work with ve and {{cite web}} does, what about the other 25 cs1|2 templates? Do they also not work with ve? If not, seems like a huge ve bug to me. Talk to the ve maintainers.

—Trappist the monk (talk) 13:28, 10 October 2022 (UTC)

Another generic title

Hello, can you add "Security Check Required" to the list of generic titles. There are currently 211 instances, mostly from Facebook references. Keith D (talk) 16:32, 13 October 2022 (UTC)

Another one to add is "IMDB" as the full title. Ignoring case there are 244 instances. Keith D (talk) 00:08, 15 October 2022 (UTC)

others = Illustrated by ...

The rubric currently says that the right way to include an illustrator is with the "others" parameter and the words "Illustrated by A. R. Tist". This is a kludge, where we should have parameters "illustrator = " and "illustrator-last = ", "illustrator-first = ". Perhaps that implies "illustratorN =" which I can see means a further slice of work if we're to allow multiple illustrators, which certainly sometimes happens. Still, it'd be the tidy solution. Chiswick Chap (talk) 20:05, 14 October 2022 (UTC)

This is a perennial request that has not yet been backed up with analysis that shows the need for it, either for WP:V reasons or because "illustrator" is a useful and widely used value in |others=. We could add all sorts of trivia about our sources, but why? – Jonesey95 (talk) 22:11, 14 October 2022 (UTC)

Use of "oclc="

OCLC numbers can be useful, and I'm happy that Cite book provides the field. My question is about when one should use it. (It may therefore be off-topic here. You're welcome to tell me where I should post this instead of here.)

Most recent editions of books have ISBNs. An edition that has an ISBN probably appears in Worldcat, and if so has one or more OCLC records. If there are two or more OCLC records (as is common), it's often not obvious which is the most informative or the most accurate, let alone the one most likely to cover libraries within readers' reach. Anyway, if an edition has an ISBN, this will normally* make it easy to find the OCLC number(s). So whether or not I use a Cite template, my own practice is to provide the ISBN of an edition where there is an ISBN, and to cite an OCLC number only where there isn't an ISBN. If provided together with an ISBN, an OCLC number is IMHO normally* mere clutter. And so I've taken to removing the OCLC numbers (example). Comments? (* Yes, there are cases where some mistake has resulted in a single ISBN being shared by two books sharing nothing but a publisher. Of course I'm in favour of OCLC numbers that disambiguate.) -- Hoary (talk) 23:30, 14 October 2022 (UTC)

I provide OCLC if there is no ISBN. I don't see a reason to remove them if they lead to the source in question. It's one fewer hop for the reader to finding actual information about the book. – Jonesey95 (talk) 00:23, 15 October 2022 (UTC)

Personally, I add OCLC numbers even if there is an ISBN, because the OCLC number link will jump right to Worldcat, while the ISBN link jumps to the Special:BookSources page. Yes, you can get to Worldcat from Special:BookSources, but for readers in the know, it's one less step to just use the OCLC. For other source types, such as periodicals, an ISSN jumps right to Worldcat, so I don't see a need to double up. Imzadi 1979 → 00:23, 15 October 2022 (UTC)

Thank you both for your comments. One point, though. Imzadi1979, you talk of "the OCLC" as if a given ISBN corresponds to a single OCLC number. However, in my experience, far more often it corresponds to a bunch of OCLC numbers. Where it corresponds to a number of them, how do you choose among them: the most informative entry (regardless of spelling, etc), the entry with the most conscientious use of diacritics (regardless of a lack of a chapter listing, etc), the entry listing the most libraries? (Worse, I'd guess that many people presented with an OCLC number for an edition would wrongly assume that it is the sole, definitive OCLC number for it.) -- Hoary (talk) 00:54, 15 October 2022 (UTC)

OCLC identifiers correspond to existing works in libraries (and other repositories). As these entities have disparate cataloguing schemes, the id is a way to unify presentation of these holdings. Theoretically, any OCLC for a unique ISBN is acceptable: the work can be discovered in the related institution and perhaps be consulted for verification. Practically, it is probably better to use an OCLC from an institution with known, large resources. Such an institution may be more easily able to supply the work reviewed. But your main thrust is correct. There is a localization issue here. 71.105.141.131 (talk) 01:09, 15 October 2022 (UTC)

Personally, I only include |oclc= when there is no ISBN and when other criteria apply. The main one is when it's otherwise be tricky to locate a source from the rest of the given citation information (e.g., super common titles or surnames, complicated titles where I can imagine libraries might disagree about how to enter the title, non-English titles where transliteration schemes come into play, etc.). Also, if a work (again without an ISBN) is in so few libraries where there is a single definitive OCLC number because only one or two libraries has something, I might also use an OCLC since that helps people more easily see how few libraries something is in. But since multiple OCLC numbers can exist I tend to avoid one since it might not be the right OCLC for a given user and might give them a false sense of which libraries near them have it -- when there are multiple OCLCs I'll somewhat arbitrarily pick the one with the most libraries using it. Umimmak (talk) 01:15, 15 October 2022 (UTC)

@Hoary: I've run into just this situation a few times. I work with some annually published sources that are indexed by some libraries as individual publications, and by other libraries as annual editions of a serial/periodical. So these sources often have two OCLC identifiers, one for the series, and one for each year. In that case, I list both. I use |id={{OCLC|1|2}} so that both appear. In a few rare cases, an individual edition has had three OCLCs because libraries break the series into different overlapping runs of years, but again, I just list them all so that readers can easily search in Worldcat for a library holding the source. Imzadi 1979 → 01:44, 15 October 2022 (UTC)

Thank you, Jonesey95, Imzadi1979, 71.105.141.131, Umimmak. In future, I'll refrain from removing OCLC numbers (unless of course they're obviously misleading or mistaken). I'm very surprised to read of |id={{OCLC|1|2}}. I hadn't been aware of the possibility. This isn't something I'd often want to use; but |id={{ISBN|1|2}} would be. Perhaps digressing here, but can Cite book be nudged to produce a version with short descriptions, something like "ISBN 9780195381979 (hardback), 9780190621056 (paperback)"? Believing (or just lazily assuming) that it can't is one reason why I'm seldom keen to use Cite book, though I understand its benefits and don't undo others' use of it. -- Hoary (talk) 23:22, 16 October 2022 (UTC)

Well per WP:SAYWHEREYOUGOTIT an individual editor is presumably only consulting one version of a book; it would be rare that someone is consulting both the paperback and hardcover versions. It's also possible hardback vs paperback would have different paginations, also often paperback editions have some kind of update, have a different year of publication, etc. It would be confusing to list multiple ISBNs for a single citation.

An exception I guess would be in a MOS:LISTOFWORKS section of an author, but even then it's probably an unnecessary level of detail to provide information about all editions of a book.

{{ISBN}} allows the use of something like {{ISBN|978-1-4133-0454-1|978-1-4133-0454-1|978-1-4133-0454-1}} ISBN 978-1-4133-0454-1, 978-1-4133-0454-1, 978-1-4133-0454-1 but not with providing a parenthetical description for each ISBN. Umimmak (talk) 23:41, 16 October 2022 (UTC)

You can use |type=medium/binding with the corresponding ISBN. Use only the ISBN you consulted, bindings may have different outlines/layouts including elements such as pagination. 50.75.226.250 (talk) 16:06, 17 October 2022 (UTC)

T221625

The code reference phab:T221625 which is marked as invalid. Should the workaround get removed or if it still required then it would be nice to update that phab task. Eran (talk) 11:56, 15 October 2022 (UTC)

This is about the comment at Module:Citation/CS1/Configuration line 620? Has ve been changed? Does a new page created using ve have content that is available to Scribunto's mw.title.getCurrentTitle():getContent()? If one or both answers is 'no', then the 'workaround' to set content to empty string when mw.title.getCurrentTitle():getContent() returns nil is still required. That 'workaround' is probably a good idea in case mw.title.getCurrentTitle():getContent() returns nil for some other unexpected reason.

I see no need to update the phab task because the reason for closure as invalid is provided at phab:T221625#5130642.

The original discussion linked from phab:T221625 is archived at Help talk:Citation Style 1/Archive 55 § Broken citation module.

—Trappist the monk (talk) 13:29, 15 October 2022 (UTC)

Book published by two separate publishers in two separate locations

I'm trying to use the template for a book that has been published by two separate publishers, each having their own separate location. But in the template, there is only the possibility for one publisher and one location. How to solve this? Thanks in advance. Roelof Hendrickx (talk) 12:40, 15 October 2022 (UTC)

WP:SAYWHEREYOUREADIT. If you consulted both, cite both, but cite them independently (two {{cite book}} templates). If you consulted only one, cite that one, and don't bother with the other.

—Trappist the monk (talk) 13:07, 15 October 2022 (UTC)

I think you don't understand what I meant. It are not two publications, it's one publication, published by two separate publishers. For example: Vorsterman van Oyen, A.A. (1882). Het vorstenhuis Oranje-Nassau. Van de vroegste tijden tot heden (in Dutch). Leiden: A.W. Sijthoff/Utrecht: J.L. Beijers. Regards, Roelof Hendrickx (talk) 13:11, 15 October 2022 (UTC)

I did a google search for the book title. Amazon uses: Leiden/Utrecht: Sijthoff & Beijers; WorldCat lists a variety of forms reflective of Leiden en Utrecht: A.W. Sijthoff en J.L. Beijers. This source appears to have been used at Henry I, Count of Nassau.

The real question is which location belongs to which publisher? Do both publishers have branch offices in both cities? Are they separate? Are Sijthoff and Beijers partners somehow? How are these names and locations presented in the book's front matter?

—Trappist the monk (talk) 14:51, 15 October 2022 (UTC)

The front page reads Leiden en Utrecht, A.W. Sijthoff en J.L. Beijers. A.W. Sijthoff was located in Leiden, and J.L. Beijers in Utrecht. They were not partners, but separate publishers. Both publishers do not excist anymore. This source is used in several articles about the counts of Nassau. Roelof Hendrickx (talk) 15:14, 15 October 2022 (UTC)

Here's what CMoS 17 says:

When books are published simultaneously (or almost so) by two publishers, usually in different countries, only one publisher need be listed—the one that is more relevant to the users of the citation. For example, if a book copublished by a British and an American publisher is listed in the bibliography of an American publication, only the American publication details need be given. If for some reason (e.g., as a matter of historical interest) information is included for both publishers, a semicolon should be used as a separator. [...] Lévi-Strauss, Claude. The Savage Mind. Chicago: University of Chicago Press; London: Weidenfeld and Nicolson, 1962.

So just pick one, I tend to just go with the first one. Umimmak (talk) 15:11, 15 October 2022 (UTC)

This book was published in the Netherlands only, not in two countries. It was quite common for Dutch publishers to cooperate and publish a book both. It still happens today. In Dutch lists of literature or sources, it has always been customary to mention both publishers. But the main question is, how can I get your example Chicago: University of Chicago Press; London: Weidenfeld and Nicolson in the template cite book. Roelof Hendrickx (talk) 15:19, 15 October 2022 (UTC)

You wouldn’t be able to use the citation templates for that sort of example. If it’s that important for you to include both in that format, which again, is generally not required or expected, then you’d have to eschew the citation templates and write it out yourself. Umimmak (talk) 15:23, 15 October 2022 (UTC)

Thanks for clarifying that I cannot use the cite book template for it. Roelof Hendrickx (talk) 17:13, 15 October 2022 (UTC)

I have seen people cite both. I assume I've seen people cite only one. I don't think Chicago is unreasonable here and fundamentally don't think citing both is unreasonable here. Izno (talk) 15:54, 15 October 2022 (UTC)

Can a reader find the work if only one of the publishers is cited? That is the only pertinent question. Depending on the answer you have several correct options, almost all of them ugly:

• AuthorName. Title. Location1; Location2: Publisher1; Publisher2.{{cite book}}: CS1 maint: location (link) [the actual location/publisher pairs are easily discovered]
• AuthorName. Title. Location1, Location2: Publisher1, Publisher2.{{cite book}}: CS1 maint: location (link) [alternate list separator]
• AuthorName. Title. Location1 and elsewhere: Publisher1 et al.{{cite book}}: CS1 maint: location (link) [alternate list rendering]
• AuthorName. Title. Publisher1; Publisher2. [no location]
• AuthorName. Title. Location1: Publisher1.{{cite book}}: CS1 maint: location (link) (Published by consortium of publishers based in multiple locations.) [with external note]

65.88.88.237 (talk) 16:19, 15 October 2022 (UTC)

Absolutely necessary perhaps not, but leaving one publisher out is not what I prefer to do. I think the options Leiden: A.W. Sijthoff/Utrecht: J.L. Beijers or Leiden: A.W. Sijthoff; Utrecht: J.L. Beijers make it clear. Even if I cannot use the template. Thanks anyway for thinking with me for a solution. Roelof Hendrickx (talk) 17:17, 15 October 2022 (UTC)

@Roelof Hendrickx: I was curious what the MLA Handbook said; in general it doesn't require the city of publication for modern (post-1900) books and separates publishing houses with slashes which you could do with CS1 templates (|publisher=Iberoamericana / Vervuert / Librería Sur). For pre-1900 books it recommends only listing the city of publication and not a publishing house; it doesn't explicitly mention how to cite copublished works when it's deemed important to cite cities of publication but you could I imagine just have either |location=Leiden / Utrecht or |publisher=A.W. Stijthoff / J.L. Beijers if you wished to go a more MLA style route -- and that you could do in CS1.

Again, I think I'd defer to Chicago style and just picking one publishing house myself though. Umimmak (talk) 22:11, 16 October 2022 (UTC)

Thanks for your reply. I go check it. Roelof Hendrickx (talk) 07:48, 17 October 2022 (UTC)

CS1 maint: extra punctuation issue

In the article Hadean, reference #39 states "CS1 maint: extra punctuation issue" because the |doi= parameter value ends with a semi-colon. However, it seems that the semi-colon is necessary for the doi link to work.

• "This doi link works". Journal. doi:10.1130/G25031A.1;.{{cite journal}}: CS1 maint: extra punctuation (link)
• "This doi link generates a DOI not found error". Journal. doi:10.1130/G25031A.1.

Is it possible to exempt the |doi= parameter from this maintenance message? Thanks! GoingBatty (talk) 00:08, 16 October 2022 (UTC)

You can do this to suppress the CS1 maint: extra punctuation categorization:

{{cite journal|title=This doi link works|journal=Journal|doi=((10.1130/G25031A.1;))}}

"This doi link works". Journal. doi:10.1130/G25031A.1;.{{cite journal}}: CS1 maint: ignored DOI errors (link)

Of course, that brings with it the CS1 maint: ignored DOI errors maintenance category...

—Trappist the monk (talk) 00:41, 16 October 2022 (UTC)

No longer able to have month abbreviations?

Per Help:CS1_errors#bad_date the |date= field should allow any format in MOS:DATE. MOS:DATE allows month abbreviations: Only in limited situations where brevity is helpful: For use in tables, infoboxes, references, etc. Only certain citation styles use abbreviated date formats. By default, Wikipedia does not abbreviate dates. Use a consistent citation style within any one article.

Particularly for dates that contain a range of months, it can be useful for the date to read, say (Nov–Dec 2020) instead of (November–December 2020). However, despite MOS:DATE allowing month abbreviations to be used in references, it seems that CS1 automatically converts month abbreviations to the full month when I try putting the following in To Shiver the Sky#Further reading, although I can't reproduce the effect here...

• Vroon, Donald (Nov–Dec 2020). "Tin: To Shiver the Sky". American Record Guide. 83 (6): 105–106. ProQuest 2455946505.

Here I have |date=Nov–Dec 2020 and what reads is (Nov–Dec 2020), but in To Shiver the Sky#Further reading the above template automatically produces November–December 2020, at least on my end.

Does anyone know what is causing this automatic conversion of month abbreviations to full month names?

Umimmak (talk) 21:54, 16 October 2022 (UTC)

I see now this has something to do with {{Use dmy dates}}, so I guess this has nothing to do with CS1, but I definitely find it inconvenient that this changes citations from how I've entered them, but perhaps the concept of only using month abbreviations when they're a part of ranges in a citation is not an entirely consistent stylistic decision. Umimmak (talk) 21:57, 16 October 2022 (UTC)

It technically does have something to do with CS1, which gets the page content (CS1 is the predominant reason pages transclude themselves these days), and uses the use X date template to automatically format its properly-inputted dates to be consistent on output by design, rather than by accident. But that has a general consensus in place, which I do not expect to go anywhere. Izno (talk) 22:16, 16 October 2022 (UTC)

Template:Use dmy dates#Auto-formatting citation template dates lists various options so that CS1 can consistency apply variants on the date format. I believe one of those would allow abbreviated months. Imzadi 1979 → 22:41, 16 October 2022 (UTC)

Also documented at Help:Citation Style 1#Auto-formatting citation template dates. —David Eppstein (talk) 23:07, 16 October 2022 (UTC)

Update SSRN limit

The following citation does not work:

• Sirin, Selahattin Murat; Camadan, Ercument; Erten, Ibrahim (17 Sep 2022). "Market Failure or Politics? A Systematic Review of Literature on Price Spikes and a Case Study of the Regulatory Responses to Surging Electricity Prices in European Countries". SSRN 4221661.

even though 4221661 is a perfectly valid SSRN id. Викидим (talk) 20:14, 17 October 2022 (UTC)

|ssrn= required is a weird error for this case. :) Izno (talk) 21:06, 17 October 2022 (UTC)

|ssrn= required error is one shared by the other preprint templates. Module:Citation/CS1/Utilities makes two lists of identifiers; one is sequence of all pretty-like identifiers and their values for rendering and the other is k/v table where k is the identifier and v is its value for COinS (which does not need to be pretty). Some time ago we decided to inhibit metadata generation for invalid identifier values. When invalid, the identifer and its value are omitted when Module:Citation/CS1/Utilities creates the k/v table.

Module:Citation/CS1 used the k/v table to determine if the identifier parameter that is required for the current preprint template is present. Alas, because invalid parameters are not listed, the module returns the unexpected required-parameter-missing error. Fixed in the sandbox:

• {{cite arxiv/new |author=EB Green |title=Title |arxiv=1234}}
  • EB Green. "Title". arXiv:1234. {{cite arXiv}}: Check |arxiv= value (help)
• {{cite arxiv/new |author=EB Green |title=Title |arxiv=}}
  • EB Green. "Title". {{cite arXiv}}: |arxiv= required (help)
• {{cite arxiv/new |author=EB Green |title=Title |eprint=1234}}
  • EB Green. "Title". arXiv:1234. {{cite arXiv}}: Check |arxiv= value (help)
• {{cite arxiv/new |author=EB Green |title=Title |eprint=}}
  • EB Green. "Title". {{cite arXiv}}: |arxiv= required (help)
• {{cite biorxiv/new |title=Title |biorxiv=1234}}
  • "Title". bioRxiv 1234. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=}}
  • "Title". {{cite bioRxiv}}: |biorxiv= required (help)
• {{cite citeseerx/new |title=Title |citeseerx=1234}}
  • "Title". CiteSeerX 1234. {{cite CiteSeerX}}: Check |citeseerx= value (help)
• {{cite citeseerx/new |title=Title |citeseerx=}}
  • "Title". {{cite CiteSeerX}}: |citeseerx= required (help)
• {{cite ssrn/new |title=Title |ssrn=abcd}}
  • "Title". SSRN abcd. {{cite SSRN}}: Check |ssrn= value (help)
• {{cite ssrn/new |title=Title |ssrn=}}
  • "Title". {{cite SSRN}}: |ssrn= required (help)

—Trappist the monk (talk) 23:19, 17 October 2022 (UTC)

jstor-access

JSTOR requires registration (at least for some articles). So why |jstor-access=registration is "Invalid"? — Mikhail Ryazanov (talk) 19:29, 20 October 2022 (UTC)

Been asked before. The probable answer is myopic design, which results into locking possible parameter values to a limited range. As is usually the case, fixing bad software design after production is much harder, as it may involve dependencies, which could have been originally there, or appeared later as the software develops. 68.174.121.16 (talk) 22:00, 20 October 2022 (UTC)

cite journal: starting with a stop

Minor problem with {{cite journal}}:

• {{cite journal |display-authors=0 |translator-last=Toft |translator-first=Peter |last=Holberg |first=Ludvig |title=Title |journal=Magazine}} (suppressed author)
  • "Title". Magazine. Translated by Toft, Peter.
• {{cite journal |translator-last=Toft |translator-first=Peter |title=Title |journal=Magazine}} (absent author)
  • "Title". Magazine. Translated by Toft, Peter.

In both cases, the template leaves an orphan period at the beginning. I'm doing similar stuff with {{cite book}} and am not seeing this problem. These are unusual cases, and obviously not a huge deal, but I thought I'd point them out. Cheers. Phil wink (talk) 02:51, 21 October 2022 (UTC)

Consider using |author-mask=.

• {{cite journal |author-mask=1 |translator-last=Toft |translator-first=Peter |last=Holberg |first=Ludvig |title=Title |journal=Magazine}} (suppressed author)
  • —. "Title". Magazine. Translated by Toft, Peter.

I think that is the recommended solution. If not, please link to the article where you are trying to use this unusual format, and we may be able to recommend a workaround. – Jonesey95 (talk) 04:18, 21 October 2022 (UTC)

Unsigned journal articles are normally assumed to be authored by an editor/editor team (of the entire journal or of the department the article belongs to). I would use the editor info. In the other case, as Jonesey95 suggested, suppressing author display in lists is properly done through masking.

However you are correct in pointing out the orphan field separator (dot). Fixing this cosmetic error is probably low on the totem pole of things to do. 71.247.146.98 (talk) 12:17, 21 October 2022 (UTC)