Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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)

Another one to add is titles containing "This page has been removed", currently 34 articles. Keith D (talk) 23:19, 24 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)

Umimmak and IP, perhaps a problem is the vagueness of the term edition. (Book is even vaguer, but the vagueness is widely recognized.) Of course I don't have in mind basing edits to the (currently feeble) article on Call It Sleep on what I see in a Penguin copy, calling that "paperback", and adding a Library of America edition (which I haven't seen) as the "hardback", for both specifying pp 203–208 (because that's where it is in the Penguin). There are, after all, limits to my ineptitude. What I have in mind will be exemplified by Daniel White's Administering affect: Pop-culture Japan and the politics of anxiety. Unsurprisingly for an academic book, its copyright page tells us:

Identifiers: LCCN 2021049474 (print) | LCCN 2021049475 (ebook) | ISBN 9781503630680 (cloth) | ISBN 9781503632196 (paperback) | ISBN 9781503632202 (ebook)

Putting aside questions related to the "ebook", each page of the "cloth" edition and the paperback will be identical. -- Hoary (talk) 00:03, 24 October 2022 (UTC)

There maybe a lot of bibliographic information in the copyright page, but not all of it is useful or necessary for citations in Wikipedia. The simple rule is that we (as readers) need to know where/how you, as the citation writer, found the info. This is the easiest way of verifying the related wikitext. If the book has several identifiers for the specific edition/binding you consulted, they may be listed, since they presumably use different catalogs: if a book cannot be found in the ISBN catalog it may be found in the LCCN catalog, etc. 50.75.226.250 (talk) 14:48, 24 October 2022 (UTC)

That's true. With luck, somebody wanting to look something up in a book of this kind (or indeed wanting to read it from cover to cover), clicking on the sole ISBN provided, and not finding a copy within reach, will think of the possibility of a differently-bound edition with its own ISBN, and use Worldcat or similar to find it. I think it would be helpful to provide (i) the ISBN of a second edition as long as this was certain to have the same pagination, and (ii) a simple explanation of which ISBN was which; but perhaps the benefit would be outweighed by the risk of well-intended misapplications. -- Hoary (talk) 22:15, 24 October 2022 (UTC)

Worldcat does have the option to find other editions of a publication. Sometimes that gets you the listings for a 2nd or 3rd edition when you searched for the 1st, and sometimes that gets you alternate bindings or sister imprints and the like. Imzadi 1979 → 23:40, 24 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)

You could leave out the locations entirely and just list the two publisher names separated by a comma or a semicolon –jacobolus (t) 02:25, 7 November 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)

Thanks, and -- before I go on -- I do want to emphasize that I'm not demanding action here; just thought it would be useful to register the phenomenon. I'm fine if the resolution is "yeah, sorry to hear about your little dot." The article is currently in userspace: User:Phil_wink/lheng. moved to mainspace 2022-10-22: List of Holberg's plays in English translation. As you'll see, the entries in question constitute an entire section with a single author (Ludvig Holberg). So it would be purposeless and busy to list him repeatedly, and overly spikey to fill the section with author masks. But I do want to keep him in the data, both for bibliographic completeness, and to facilitate the {{citeref}}s in the table. Oh, the entry in question ("Toft") is the second entry under Individual dramas. Cheers. Phil wink (talk) 14:18, 21 October 2022 (UTC)

This is an |others= problem so is a problem for |translator= and |interviewer= when using {{cite journal}} or any |periodical= alias with {{citation}} because in those rendered citations, the |others= value follows the author and editor name-lists. This is different from the other cs1|2 templates. Why is there a difference? No idea; apparently, ever thus:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|others=EB Greene|title=Title}}
Old	. EB Greene"Title". Journal.
Live	"Title". Journal. EB Greene.{{cite journal}}: CS1 maint: others (link)

Cite book comparison

Wikitext	{{cite book|others=EB Greene|title=Title}}
Old	Title. EB Greene.
Live	Title. EB Greene.{{cite book}}: CS1 maint: others (link)

fixed in the sandbox:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|others=EB Greene|title=Title}}
Live	"Title". Journal. EB Greene.{{cite journal}}: CS1 maint: others (link)
Sandbox	"Title". Journal. EB Greene.{{cite journal}}: CS1 maint: others (link)

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|title=Title|translator=EB Greene}}
Live	"Title". Journal. Translated by EB Greene.
Sandbox	"Title". Journal. Translated by EB Greene.

Cite journal comparison

Wikitext	{{cite journal|interviewer=EB Greene|journal=Journal|title=Title}}
Live	"Title". Journal. Interviewed by EB Greene.
Sandbox	"Title". Journal. Interviewed by EB Greene.

Citation comparison

Wikitext	{{citation|journal=Journal|others=EB Greene|title=Title}}
Live	"Title", Journal, EB Greene{{citation}}: CS1 maint: others (link)
Sandbox	"Title", Journal, EB Greene{{citation}}: CS1 maint: others (link)

Citation comparison

Wikitext	{{citation|journal=Journal|title=Title|translator=EB Greene}}
Live	"Title", Journal, translated by EB Greene
Sandbox	"Title", Journal, translated by EB Greene

Citation comparison

Wikitext	{{citation|interviewer=EB Greene|journal=Journal|title=Title}}
Live	"Title", Journal, interviewed by EB Greene
Sandbox	"Title", Journal, interviewed by EB Greene

But, is this the right fix? Shouldn't all cs1|2 templates render |others= in more-or-less the same position? This fix has the obvious 'new' flaw in cs2 where the first letter of the static text in the rendering is lowercase. Not quite sure how to fix that and support i18n. Is this a case where we require |translator= and |interviewer= to have a displayed value for |author= or |editor=?

—Trappist the monk (talk) 14:58, 21 October 2022 (UTC)

I would think that it is a no-brainer for the presentation of any element in a citation (including the positioning) to be consistent throughout. Compliance with i18n is secondary. Uniformity and proper grammar in the wiki's local language should always take precedence. Making secondary roles such as "translator" dependent on the display of a primary role such as "author" or "editor" seems logical, and something that could be expected by readers (including when the author is listed as "Unknown"). I have to say that the OP's application of the templates is not as citations, but as bibliographic entries in a List of Works (in this case, a list of translations of works). Imo, CS1/2 is not a good fit for the OP's specific application. 50.75.226.250 (talk) 15:30, 21 October 2022 (UTC)

Reuters and Business as generic last names

Could Reuters be added as a generic value of the |last= parameter in Module:Citation/CS1/Configuration? There are some two thousand pages that use it (Special:Search/insource:"last=Reuters"). Kleinpecan (talk) 08:31, 23 October 2022 (UTC)

Similarly, Business when used alone could also be added as a generic last name value. This seems very common with references to CNN Business (Special:Search/insource:"last=Business"). Kleinpecan (talk) 08:39, 23 October 2022 (UTC)

Different searches give (of course) different results:

with 'Reuters' anywhere in the assigned value for:

• |authorn= ~475 (times out)
• |lastn= ~420 (times out)
• |firstn= ~170 (times out)

with 'Business' anywhere in the assigned value for:

• |authorn= ~700 (times out)
• |lastn= ~390 (times out)
• |firstn= ~710 (times out)

And, because 'Business' is so often associated with 'CNN':

with 'CNN' anywhere in the assigned value for:

• |authorn= ~1000
• |lastn= ~450
• |firstn= ~470

And because 'Business' is also commonly associated with 'Inc' or 'Inc.':

with 'Inc' or 'Inc.' as the whole assigned value for:

• |authorn= ~5 (times out)
• |lastn= ~1210 (times out)
• |firstn= ~145 (times out)

So, to the sandbox I have added 'Reuters', 'Business', and 'CNN' as plain text finds; and added ^[Ii]nc%.?$ as a pattern match find.

—Trappist the monk (talk) 14:42, 23 October 2022 (UTC)

access-date in the TOC

At {{Cite web}}, I cannot find |access-date= in the /documentation TOC, nor anything like it. Is that by design? (if so, what can I learn?). Otherwise, please add it. DePiep (talk) 08:29, 25 October 2022 (UTC)

It's under URL, since |access-date= requires |url= to be present. I recommend using the Find feature of your browser. – Jonesey95 (talk) 15:02, 25 October 2022 (UTC)

Well, a Do Find is saying TOC is not working. Anyway § url may be the logical place by the module code designers, but not for /doc functioning. The dependency-placement is a surprise. (/doc-wise, such a dependency can/should be mentioned with the (proposed) access-date entry, not overtaking it). DePiep (talk) 21:19, 25 October 2022 (UTC)

Added to TOC, referencing to § url. [1]. Unlike in e.g. the last2, first2 relationship, this does not unastonishingly follow from url (non-intuitive relationship). Being prerequisited does not answer documentation requirementsd. {{csdoc}} to be adjusted? -DePiep (talk) 06:38, 2 November 2022 (UTC)

citeseerx links are ALL dead

It seems that the 10.***** citeseerx links seems to no longer work. AManWithNoPlan (talk) 13:06, 25 October 2022 (UTC)

Looks like citeseerx changed something and broke ~17,000 articles using |citeseerx= and ~930 articles using the base url that cs1|2 uses. No doubt, there are broken links at other-language wikis as well because many other-language wikis copy articles with their citations from us...

It will not be me, but someone should tell citeseerx that they have done a bad thing...

—Trappist the monk (talk) 13:42, 25 October 2022 (UTC)

And if you do a "view source" on the new pages, the 10.* number is NOT there. "I felt a great disturbance in the Wiki, as if millions of Unique IDs suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened." AManWithNoPlan (talk) 14:20, 25 October 2022 (UTC)

I have submitted an e-mail through their Contact Us page, FWIW. – Jonesey95 (talk) 15:06, 25 October 2022 (UTC)

API worked on 2022-10-12, but failed on 2022-10-17. Very recent. AManWithNoPlan (talk) 21:29, 28 October 2022 (UTC)

@Jonesey95: any word? AManWithNoPlan (talk) 13:10, 3 November 2022 (UTC)

No response. I even checked my spam folder. – Jonesey95 (talk) 18:25, 3 November 2022 (UTC)

It certainly broke. All citeseerx hits on Google are broken. I've been checking to see if anyone on the internet had noted this (or if it was just me), and so far this post is the only notice I've found. Micler (talk) 14:21, 3 November 2022 (UTC)

Protected edit request on 25 October 2022

I often like to copy the vertical format from the template page when writing a new reference. I think it would improve readability to editors if the "="-signs were directly below each other, like some other citation templates.

The length that appears in other templates, appears to have been chosen in order to have a space before and after " archive-date = ". (And a space after the "="-sign).

I think this should be fairly uncontroversial as it only improves readability.

(Please look at the source-text for this edit-request as I'm unable to display it as plain text due to all the pipes. And I can't see the source-text of the existing templates to inform me of how it should be entered. I have tried "tlx" and "code". They either don't work or they ignore spaces.)

This should be the result of changing the existing vertical format boxes:

Under "Template:Cite web#Usage#Most commonly used parameters in vertical format":

{{cite web
| url          = 
| title        = 
| last         = 
| first        = 
| date         = 
| website      = 
| publisher    = 
| access-date  = 
| quote        = }}

And under "Template:Cite web#Usage#Full parameter set in vertical format":

{{cite web
| url          = 
| url-access   = 
| title        = 
| last         = 
| first        = 
| author-link  = 
| last2        = 
| first2       = 
| author-link2 = 
| date         = 
| year         = 
| orig-date    = 
| editor-last  = 
| editor-first = 
| editor-link  = 
| editor2-last = 
| editor2-first= 
| editor2-link = 
| department   = 
| website      = 
| series       = 
| publisher    = 
| agency       = 
| location     = 
| page         = 
| pages        = 
| at           = 
| language     = 
| script-title = 
| trans-title  = 
| type         = 
| format       = 
| arxiv        = 
| asin         = 
| bibcode      = 
| doi          = 
| doi-broken-date= 
| isbn         = 
| issn         = 
| jfm          = 
| jstor        = 
| lccn         = 
| mr           = 
| oclc         = 
| ol           = 
| osti         = 
| pmc          = 
| pmid         = 
| rfc          = 
| ssrn         = 
| zbl          = 
| id           = 
| access-date  = 
| url-status   = 
| archive-url  = 
| archive-date = 
| via          = 
| quote        = 
| ref          = 
| postscript   = }} 

BucketOfSquirrels (talk) 20:42, 25 October 2022 (UTC)

 Not done the page your requested an edit to doesn't contain that wikitext. If you want to change the documentation, you can do so here: Template:Cite web/doc. — xaosflux ^Talk 20:53, 25 October 2022 (UTC)

Outdated example

Under Publisher, it gives the example "Example: [ [CBS Interactive] ] (which owns 'Metacritic.com')". This is outdated, as CBS Interactive no longer owns Metacritic. spongeworthy93 talk  15:04, 26 October 2022 (UTC)

If you are referring to a documentation page, those pages are not protected and may be edited by anyone. You are free to fix it.

In future, because this talk page is the target of a lot of redirects from template, module, ~/doc, ~/sandbox, ~/testcases talk pages, please say where you find the problem.

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

Physical address of Republic of Molossia

I noticed that some user put the physical address in Republic of Molossia in {{cite web}}: |location= 226 Mary Lane, Dayton, Nevada 89403. Nevertheless, this caused CS1 to output a maintenance error. I tried to fix it writing |location=Mary Lane|publication-place=Dayton, Nevada but there's no way to insert the numbers. Is there a way to fix it? Thanks in advance.- Carnby (talk) 07:05, 29 October 2022 (UTC)

There are several issues with the article, including lack of clarity over the use of primary sources, but to narrowly answer your question, |location=locality where publisher is based. The full or partial address is not required, and it actually generates clutter. 65.88.88.68 (talk) 14:26, 29 October 2022 (UTC)

The very reason the error exists is because of the numbers. We have no need for the street-level location. |location=Dayton, Nevada is sufficient. Izno (talk) 20:09, 29 October 2022 (UTC)

Change to use #invoke?

Hi, an editor went through COVID-19 and changed all the cites and changed cite with a single pipe to #invoke:Cite with a double pipe. Is this considered standard now? X750. Spin a yarn? _{Articles I've screwed over?} 20:07, 30 October 2022 (UTC)

For pages with a HUGE number of templates, this is necessary. AManWithNoPlan (talk) 21:03, 30 October 2022 (UTC)

Hi AManWithNoPlan, sorry to bother, but I've got another question. I am giving an article a rewrite, and it's becoming fairly large. As it stands, the amount of citation templates is about 150, and I expect it to reach 250. Should I change to invoke as well? Thanks. X750. Spin a yarn? _{Articles I've screwed over?} 19:23, 2 November 2022 (UTC)

If you get error messages, and only if you get error messages. AManWithNoPlan (talk) 19:27, 2 November 2022 (UTC)

It a mechanism that allows editors to hold-off tough editorial control decisions because it helps to keep post-expand include size within limits. But, it is only a stop-gap. This version of COVID-19 (the current version as I write this) has a post‐expand include size of 1,993,186/2,097,152 bytes; 103,966 bytes shy of the limit. Eventually, post‐expand include size will exceed the 2MB limit and editors who have been putting it off and putting it off will have to pare-down the article or split it.

An article's Post‐expand include size is available two ways: Edit → Show preview → Parser profiling data or Right-click → View page source → Ctrl-F search for NewPP.

—Trappist the monk (talk) 21:45, 30 October 2022 (UTC)

I see, thank you Trappist the monk. I did not realise the article was so close to the post-expand limit. X750. Spin a yarn? _{Articles I've screwed over?} 21:49, 30 October 2022 (UTC)

doi accept-this-as-written markup is being removed by WPCleaner

Help:Citation_Style_1#Accept-this-as-written_markup (double parentheses) on |doi= gets removed by Wikipedia:WPCleaner, as in Special:Diff/1119553213. I filed phab:T322177 about it, but in case it takes a while to fix, is there some way to suppress this that could be documented? Micler (talk) 05:36, 2 November 2022 (UTC)

And it's already fixed. Cool! Micler (talk) 13:40, 2 November 2022 (UTC)

Proper use of the |via= parameter in {{cite book}}

Per the documentation for Template:Cite book, this should be used when the content deliverer (e.g. NewsBank) presents the source in a format different from the original,. I was using this to indicate that I'd accessed a work through Project MUSE (ebook format rather than print copy), but it's being removed by Citation bot. Am I misunderstanding the purpose of this parameter, or is Citation bot just being a bit hyper? Hog Farm _Talk 14:15, 2 November 2022 (UTC)

If there's no URL given, |via= is pointless. WP:SAYWHERE "Note: The advice to "say where you read it" does not mean that you have to give credit to any search engines, websites, libraries, library catalogs, archives, subscription services, bibliographies, or other sources that led you to Smith's book. If you have read a book or article yourself, that's all you have to cite. You do not have to specify how you obtained and read it. " Headbomb {t · c · p · b} 14:33, 2 November 2022 (UTC)

If there is a URL given (external URL), then Template:Cite book complains:

• {{cite book |title=Foo |author=Beeblebrox |via=https://example.com}}

produces:

• Beeblebrox. Foo – via https://example.com. {{cite book}}: External link in |via= (help).

i.e. red error "External link in |via=". —Micler (talk) 15:10, 2 November 2022 (UTC)

That's because via is not meant for urls. use |url= for urls. Headbomb {t · c · p · b} 15:30, 2 November 2022 (UTC)

Ah, so the OP's situation happened because they used |via= without |url=? I evidently misunderstood. Micler (talk) 15:43, 2 November 2022 (UTC)

(edit conflict)

cs1|2 should complain. URLs go in url-holding parameters. Rewriting one of OP's example templates:

{{cite book |chapter=Mosby Monroe Parsons: Missouri's Forgotten Brigadier |chapter-url=https://muse.jhu.edu/chapter/861130 |chapter-url-access=subscription |last=Gurley |first=Bill |editor-last1=Schott |editor-first1=Thomas E. |editor-last2=Bergeron |editor-first2=Arthur W. |editor-last3=Hewitt |editor-first3=Lawrence L. |title=Confederate Generals in the Trans-Mississippi |volume=1 |publisher=University of Tennessee Press |location=Knoxville, Tennessee |date=2013 |isbn=978-1-57233-985-9 |via=Project MUSE}}

Gurley, Bill (2013). "Mosby Monroe Parsons: Missouri's Forgotten Brigadier". In Schott, Thomas E.; Bergeron, Arthur W.; Hewitt, Lawrence L. (eds.). Confederate Generals in the Trans-Mississippi. Vol. 1. Knoxville, Tennessee: University of Tennessee Press. ISBN 978-1-57233-985-9 – via Project MUSE.

The URL-holding parameters are: |archive-url=, |article-url=, |chapter-url=, |conference-url=, |contribution-url=, |entry-url=, |lay-url= (deprecated), |map-url=, |section-url=, |transcript-url=, |url=. There are a few insource parameters that accept urls: |at=, |page=, |pages=, |quote-page=, |quote-pages=. URLs also allowed in |id=.

—Trappist the monk (talk) 15:45, 2 November 2022 (UTC)

What's the benefit to even having |via= if a reader can just click on the URL to see it comes from Project MUSE? It's purely redundant information, then, no? I perhaps have misunderstood this parameter because the few times I have used it have been when there is no permanent URL or identifier, but I wish to signal to readers and editors that a resource is available online in some database. Umimmak (talk) 16:41, 2 November 2022 (UTC)

Not very much actually. AManWithNoPlan (talk) 17:52, 2 November 2022 (UTC)

I thought that I would hunt through the templates to see when |via= was added. From there I thought I might be able to find discussion on a related talk page. Amazingly, |via= has never been supported by the wikitext versions of the cs1|2 templates. I checked the obvious candidates {{citation}}, {{cite book}}, {{cite journal}}, {{cite news}}, and {{cite web}}. I also checked {{citation/core}} (the engine that renders the ~/old versions of those wikitext cs1|2 templates); |via= is not a supported parameter.

But, |via= is supported by Module:Citation/CS1 so I looked at its history. |via= was added to Module:Citation (a now-defunct predecessor to Module:Citation/CS1) at this edit; no discussion at Module talk:Citation which was created about six months after support for |via= was added to the module. But, at this discussion, a clue: {{Subscription required}} (the linked preceding discussion is archived here). There is some discussion about |via= at Template talk:Subscription required. That discussion links to User talk:Plastikspork/Archive 9 § Template:HighBeam and to Wikipedia:Templates for discussion/Log/2012 July 1 § Template:HighBeam.

—Trappist the monk (talk) 18:14, 2 November 2022 (UTC)

No templates in section headings.

—Trappist the monk (talk) 14:41, 2 November 2022 (UTC)

Why suddenly change "Spanish" to "European Spanish"?

All references with the parameter |language=Spanish now show "in European Spanish" when, in fact, many of them are from places other than Europe. Colombiaball (talk) 16:07, 3 November 2022 (UTC)

I don't think that is true:

{{cite book |title=Title |language=Spanish}}

Title (in Spanish).

Can you provide an example that shows |language=Spanish rendering as '(in European Spanish)'?

It is true that |language=es-es renders as '(in European Spanish)' but that is not your complaint:

{{cite book |title=Title |language=es-es}}

Title (in European Spanish).

—Trappist the monk (talk) 16:28, 3 November 2022 (UTC)

Thanks. Colombiaball (talk) 03:15, 4 November 2022 (UTC)

Question

When I write out the reference like this: <ref>{{cite AV media notes|title=Moment |others=Shiga Lin |year=2010 |publisher=Warner Music Hong Kong |type=booklet}}</ref>

It gives me this error: Script warning: One or more {{cite AV media notes}} templates have maintenance messages; messages may be hidden (help). {{cite AV media notes}}: CS1 maint: others in cite AV media (notes) (link) Can someone help to fix?

Thanks! --TerryAlex (talk) 03:34, 5 November 2022 (UTC)

-- add maint cat when |others= has value and used without |author=, |editor=

– Archer1234 (talk) 03:46, 5 November 2022 (UTC)

Still confused. Can you give an example? Thanks!--TerryAlex (talk) 03:48, 5 November 2022 (UTC)

If you use |others= without using |author= or |editor=, you will get that maintenance message. The only way to address is to add an author or editor and then the message will not appear. – Archer1234 (talk) 03:55, 5 November 2022 (UTC)

Got it. Thanks!--TerryAlex (talk) 04:03, 5 November 2022 (UTC)

I would not worry about this one for now. We've discussed it some but no-one has put forth a proposal on how to deal with it. The last discussion: Help talk:Citation Style 1/Archive 84#CS1 maint: others in cite AV media (notes). --Izno (talk) 04:05, 5 November 2022 (UTC)

Not true, a proposal has been suggested at the discussion you linked. Replace the AV media notes templates with parameters |contribution= and |contributor= as shown in that discussion. A special template for AV media notes makes no sense to begin with. Notes are in-source locations of the published AV media product as a whole, and they and their authors are not ever indexed afaik. This is another CS1 design flaw. 4.30.91.142 (talk) 13:22, 5 November 2022 (UTC)

|people= parenthetical roles

Prompted by Editor Izno's comment in this discussion, and these older discussions:

• Help talk:Citation Style 1/Archive 73 § CS1 maint: others
• Help talk:Citation Style 1/Archive 82 § "cite AV media notes" disallows "others="?
• Help talk:Citation Style 1/Archive 59 § Should we exclude Template:Cite AV media notes from CS1 maint: others category?

I hacked a couple of awb scripts to troll through {{cite av media}} and {{cite episode}} templates and extract the parenthetical 'role' so often included in |people=. The tabulated results are in my sandbox (permalink).

The roles are normalized to lowercase. Roles with 10 or more uses account for ~79% of the use. Of the 508 unique roles, 337 are single use. Here are the roles with ten or more uses:

most commonly used roles

role	count
director	1259
producer	210
host	138
directors	99
presenter	98
interviewee	95
interviewer	87
writer	75
guest	73
narrator	62
actor	46
performer	46
writer/director	46
producers	40
reporter	39
writers	33
editor	24
dir.	22
executive producer	21
conductor	19
speaker	19
composer	18
guests	15
1961	13
director/co-writer	13
interviewees	13
subject	13
director, producer	12
artist	11
hosts	11
interview	11
narrators	11
author	10

If we were to create a curated list of roles for {{cite av media}} and {{cite episode}}, it seems that that list should be taken from these most-commonly used roles. If we create a curated list, we can then deprecate |people=.

—Trappist the monk (talk) 17:42, 6 November 2022 (UTC)

Oh goddie! Whenever you limit the possible information that can be included in a citation template, it gives me an excuse to rewrite the citation as plain text. If there's enough of these problems in an article, I'd be justified in completely eliminating citation templates from the article. Oh by the way, movies and TV seem particularly prone to describing roles in strange ways. Jc3s5h (talk) 18:09, 6 November 2022 (UTC)

|people= is an equal alias of |authors=. We discourage the use of |authors= because it does not contribute to the citation's metadata so users who consume en.wiki citations via their metadata don't know who the 'people' are. This has been a long-ongoing issue that we should someday resolve. I have suggested more than once that we could create a curated list of roles for use in {{cite av media}} and {{cite episode}} so that editors who use those templates can use these parameters and the module would add the appropriate parenthetical annotation. Assembling the curated list is step one in that process.

—Trappist the monk (talk) 23:39, 6 November 2022 (UTC)

1. Did you count only the first instance of a parenthetical appearing? Or all parentheticals?
2. Did you look into what is happening with {{cite av media notes}}?

Izno (talk) 01:10, 7 November 2022 (UTC)

Everything in parentheses in |people= except for parenthetical wikilink dabs – nested parentheses are not well handled but there aren't many of those ... I did not look at {{cite av media notes}}.

—Trappist the monk (talk) 01:43, 7 November 2022 (UTC)

This is not the right approach. If such roles are to be codified, the role choices should be either instrumental or auxiliary in discovering the cited work. It makes no sense to include random roles just because Wikipedia editors are using them in citations 10 times or 10000 times, when they do not help in verification. Agreed-upon international cataloguing and metadata standards list a variety of usable roles (usable in the sense that catalogued works include the role nomenclature and its related person/entity in the item's description). These roles are used by all kinds of participating information repositories (trade organizations, publishers, libraries, accessible online databases etc) to list their works. Using these same roles works can be easily discovered.

It is also a good idea to keep |people= regardless. There may always be unforeseen exceptions and special cases. Assuming roles are properly codified, accepted bibliographic items such as "director" could be part of a |people= exclusion list, i.e. CS1/2 defined roles should generate an error when input in |people=. 50.75.226.250 (talk) 17:28, 7 November 2022 (UTC)